Model selection per data store
Shared tables for the cheap high-volume data, dedicated stores for the customers who pay for it and ask about it. Mixing is normal and usually correct.
Architecture
Multi-tenant web apps
The tenancy model decides your margin, your blast radius and how hard the next security questionnaire is. It is worth getting right before you have two hundred customers on it.
Pool / silo / bridgePer-tenant limitsBlast radius
What is a multi-tenant architecture?
A multi-tenant architecture serves many customers from one deployment, with each tenant's data kept separate by the application rather than by running a separate stack. On AWS the separation is done three ways: pool, silo, or a bridge that mixes both per data store.
The problem
One shared pool works until it does not
A single customer runs an unbounded query, saturates the connection pool, and everyone else sees timeouts. The fix after the fact is an emergency. The same limits put in beforehand are an afternoon of work.
3
tenancy models
p99
tracked per tenant
1
tenant cannot take the rest down
What you get
Included in the engagement
Row-level and schema-level separation
Enforced in the data layer rather than trusted to every query an engineer will write in the next two years.
Quotas and throttles
Per-tenant request rates, query timeouts and job concurrency, with headroom set from real traffic instead of a round number.
Tenant-aware observability
Logs, traces and dashboards filterable by tenant, so 'is it us or is it them' takes a minute rather than an afternoon.
How it runs
How the isolation work runs
One data store at a time. Products rarely want the same answer everywhere.
Store-by-store review
List the data stores and choose an isolation model for each one separately, rather than picking a single model for the product.
Enforce separation
Row-level policies, separate schemas or separate stores, enforced where the query runs and not in application code alone.
Quotas and throttles
Per-tenant limits on the paths that can be abused, with the limit visible to support before a customer has to report it.
Tenant-aware observability
Tenant id on logs, metrics and traces, so the question of whether it is everyone or one customer takes a minute to answer.
Prove it in CI
A test that one tenant cannot read another, running on every build, so the answer in a security review is a test result rather than an assurance.
Comparison
Pool, silo and bridge compared
The choice is per data store, not per product, and it is reversible if the tenant abstraction goes in first.
| Dimension | Pool | Silo | Bridge |
|---|---|---|---|
| Data layout | One shared store, tenant id on every row | One store per tenant | Shared for most data, dedicated for what a customer asks about |
| Cost per tenant | Lowest, capacity is shared | Highest, every tenant pays for its own idle | In between, and you choose which tenants cost more |
| Blast radius | One bad query can reach every tenant | One tenant only | Limited to the pool, siloed tenants unaffected |
| Isolation in a security review | Enforced in code, needs explaining | Separate stores, easy to explain | Answer differs per store, so document it per store |
| Onboarding a tenant | Insert a row | Provision a stack | Insert a row, or provision, depending on plan |
| Patching and schema change | One place | Every tenant environment | One place, plus the siloed few |
| Usually right for | The bulk of your customers | The regulated or very large ones | A book with both kinds in it |
Fit
Who this is for
If none of these sound like you, say so on the call and we will tell you honestly whether this is the right piece of work to start with.
- One customer's traffic has already caused an incident for everyone else.
- You are about to sign a customer far larger than the rest of the book.
- Nobody can currently answer 'what does this account cost us to run'.
Which model should we pick?
Pool for most things, silo for the data a large customer will ask about by name, bridge when you have both kinds of customer. The choice is per data store, not per product, and it is reversible if you build the abstraction first.
What is the difference between pool, silo and bridge?
Pool shares one store across all tenants and separates rows by tenant id. Silo gives every tenant its own store. Bridge pools the high-volume data and silos the parts a customer will ask about. Pool is cheapest, silo is easiest to explain to an auditor.
How do you stop one tenant affecting the others?
Per-tenant request rates, query timeouts and job concurrency caps, with the ceilings set from real traffic rather than a round number. Add a connection cap so a single customer cannot take the whole pool.
How is tenant isolation enforced in the database?
In the data access layer, not in every query an engineer writes over the next two years. Row-level security or a scoped client that cannot issue an unqualified query is what survives staff turnover.
Can we prove isolation to an enterprise buyer?
That is what the model choice is for. With silo you point at separate stores. With pool you show the enforcement point, the tests around it, and the audit trail of access per tenant. Both answers work if they are written down before the questionnaire arrives.
How do you work out what one tenant costs to run?
Tagging plus usage metering at the point work happens, so shared spend gets attributed rather than divided by headcount. It is the report that tends to change pricing conversations.
Reference
The AWS documentation we work from
Related
Work that usually comes with this
SaaS transformation
Turn a single-tenant product into a multi-tenant platform on AWS: tenant isolation, metering, self-serve onboarding and a per-tenant view of cost.
PlatformRead more
Modern app development
Containers on EKS or ECS, microservices where they earn their keep, and enough observability to debug the system at three in the morning.
BuildRead more
Compliance and security
IAM cleanup, encryption, audit trails and the evidence collection that turns a SOC 2 or ISO 27001 questionnaire into a short afternoon.
SecurityRead more
Send us your AWS bill
Thirty minutes with an engineer, no slide deck. We will tell you what we would change first and what it would cost to have us do it.