Architecture guide
Single-tenant architecture: what isolation does and does not buy.
Key takeaways
- Tenancy is a spectrum, not a binary — ask which layers are isolated, not whether the platform 'is single-tenant'.
- Isolation limits blast radius and simplifies data boundaries; it does not prevent bugs, bad configuration or capacity failure.
- The real operational benefit is often release control: the ability to not be upgraded on someone else's schedule.
What 'single-tenant' actually claims
Vendors use the term to mean anything from a dedicated database schema to fully separate infrastructure per customer. Those are very different guarantees with very different costs, and the word alone tells you neither.
The productive question is layered: is the application shared? the database? the compute? the network? the release schedule? A platform can be isolated at one layer and entirely shared at another.
What isolation at each layer buys
| Layer | Isolated | Shared |
|---|---|---|
| Database | One firm's data cannot be returned by another's query, even given a bug | A query-scoping defect can cross tenants |
| Compute | One firm's load cannot starve another's | Noisy-neighbour contention is possible under load |
| Release | You choose when to take a change | You are upgraded on the vendor's schedule |
| Configuration | Rules and limits cannot leak across firms | A misapplied default can affect several firms at once |
| Credentials | Provider keys are scoped per firm | A compromised key has wider reach |
What isolation does not solve
It does not prevent defects. A bug in shared application code ships to every isolated deployment just the same, so isolation without release control buys less than it appears to.
It does not prevent capacity failure. A dedicated instance sized incorrectly fails on its own, without help from any neighbour.
And it does not, on its own, make a claim about liquidations or execution fairness. Any suggestion that a competitor's shared infrastructure is causing your traders to be liquidated is an assertion that requires evidence, not architecture diagrams.
Questions to ask
- Which layers are isolated per firm, specifically?
- Do we control when we take a release, or are we upgraded on your schedule?
- How is data scoping enforced — by convention, by query construction, or structurally?
- How is a cross-tenant defect detected, and has one occurred?
- What does isolation cost, and is it billed to us?
Keep reading
Back to hub
Infrastructure & data
How prop firm infrastructure is architected: tenancy boundaries, matching and execution, market data licensing and how performance should be measured.
ReadRelated
Matching engine
Why a simulated execution and matching engine is built the way it is, what determinism means for evaluations, and which properties an operator should test.
ReadRelated
Technology stack
Map the systems a funded-trader firm needs, from trading and market data to CRM, risk, payments and support, and see where stacks usually break.
ReadNext step
Custom build
Build proprietary trading infrastructure on the Nexus core, with the platform, integration and operating scope shaped around your firm's own model.
ReadAsk us the layered question.
We will answer per layer, including where the honest answer is 'shared'.