In this article
Before you start
This page belongs to the distributed systems interview learning path.
Why interviewers ask this
A wrong tenancy choice shows up as one outage that hits every customer, or as a bill nobody can split by customer. Candidates report prompts about provisioning a database for each project of a hosted platform, and about broadcasting database changes to many subscribers across many projects. Both prompts test the same judgment: how much to share, and how to prove one customer cannot hurt another.
A weak answer says "one database per customer" or "one shared table with a tenant_id column" and stops. A strong answer names the spectrum, says what each end costs, separates data isolation from performance isolation, and describes the workflow that creates a tenant safely. A Staff-level answer adds placement, per-tenant limits, and how a change reaches thousands of tenants without a system-wide outage. Sizing the load first, as in back-of-the-envelope estimation, keeps the design honest.
Multi-tenant provisioning system from first principles
- Tenant
- A tenant is a customer, project or organization that uses a shared service and expects its data and performance to be separate from every other customer's, even though the provider runs one product for all of them.
- Noisy neighbor
- A noisy neighbor is a tenant whose heavy workload slows other tenants that share the same resources, such as one database or one server, so the others see worse latency without having changed anything.
- Deployment stamp
- A deployment stamp is a self-contained copy of the infrastructure that serves a tenant or a group of tenants, so capacity grows by adding stamps and a failure stays inside one stamp.
In plain words
Think of an apartment building. Each tenant has a flat, but all share the pipes, the lift and the roof. Some buildings give a few tenants a whole floor; some squeeze everyone onto shared floors. The building manager, who hands out keys and reads meters, is the provisioning system. The analogy breaks in one place: software tenants can move between buildings without moving house, so placement can change later.
In one precise sentence, a multi-tenant provisioning system turns a signup into a running, isolated, metered environment. It does so by choosing a tenancy model, applying isolation rules, running a safe creation workflow and recording where the tenant lives.
Step 1: Pick a tenancy model for each layer
Tenancy models range from fully separate to fully shared, and the standard names are silo, bridge and pool. In the Amazon Web Services (AWS) multi-tenant guidance (read 2026-10-26) a database instance per tenant is called the silo model, a dedicated schema per tenant is called the bridge model, and shared tables protected by row-level security are called the pool model.
The AWS whitepaper uses "bridge" more broadly: a mix of silo and pool across layers, for example a pooled web tier over siloed data. Keep both senses in mind. The same guidance says silo gives the strongest isolation but costs the most in money and complexity, and pool costs the least but isolates the least. It also says providers may offer service tiers so customers choose their own trade-off. You now know the first decision: choose per layer, and per tier of customer.
Step 2: Row-level security isolates data, not load
Row-level security (RLS) is a database feature that attaches rules to a table so each query sees only the rows the rules allow. It is how the pool model keeps tenants' rows apart. In PostgreSQL, tables have no policies by default, so a user with table privileges can read every row. Security applies only after row security is switched on for the table with the ALTER TABLE command's ENABLE ROW LEVEL SECURITY option, and with it on but no policy, the policy-creation page says a default-deny policy is assumed and no rows are visible.
A policy's USING clause filters rows that already exist; its WITH CHECK clause validates rows being written. A typical policy compares a tenant_id column to the caller's tenant.
A row-level policy isolates data but not load. AWS notes that heavy activity from one tenant can affect other tenants in a pool, and that cost attribution gets harder. Microsoft warns of the same noisy-neighbor risk in a shared database. So pooled tenants need separate limits, covered in the distributed rate limiter design.
Step 3: The control plane provisions, meters and retries safely
The control plane is the shared layer that makes separate stacks still count as one product. The AWS whitepaper says siloed stacks remain SaaS (Software as a Service) when surrounded by "shared identity, onboarding, metering, metrics, deployment, analytics, and operations" (AWS whitepaper, read 2026-10-26).
The sources read for this page do not describe any vendor's provisioning internals, so what follows is a standard design, not a report of how one company does it. The control plane stores the desired state of a tenant, then runs steps: create the database or schema, apply migrations, create credentials, set quotas, start metering, and register the tenant. Each step should be idempotent: an operation that gives the same result when run twice is called idempotent. Then a crash or a retry cannot create two databases for one signup. A reconciler periodically compares desired and actual state and repairs drift. Completion can be reported to the customer by a webhook.
Step 4: A tenant catalog places each tenant
A tenant catalog is a lookup table, owned by the control plane, that maps each tenant to the stamp, database or compute that serves it, so every request is routed correctly and tenants can move. The Azure Deployment Stamps pattern says a stamp may serve multiple tenants or a single one. Single-tenant stamps cost more, and multi-tenant stamps can still suffer from noisy neighbors.
Real platforms mix models. In the Supabase v2 architecture post (2024-03-20), Storage, Realtime and the connection pooler moved to shared services serving many projects, while the architecture page describes a Postgres instance for each project. Neon separates storage from stateless compute so idle databases can scale to zero; a secondary analysis notes cold starts are a cost, reduced by keeping a pool of empty virtual machines (VMs) ready.
Step-by-step description
- Choose silo, bridge or pool for each layer.
- A row-level policy isolates data, not load.
- It provisions and meters each tenant.
- A catalog maps each tenant to a stamp.
- The tenancy model sets how much of the stack tenants share.
- A row-level policy isolates data but not load.
- The control plane provisions each tenant and meters its use.
- A tenant catalog maps each tenant to the stamp that serves it.
The diagram restates the four steps. The tenancy model sets how much of the stack tenants share. A row-level policy isolates data but not load. The control plane provisions each tenant and meters its use. A tenant catalog maps each tenant to the stamp that serves it.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
Take the prompt's load: 50,000 concurrent connections across 10,000 projects (both numbers illustrative). The average is 5 connections per project, far below the Free plan cap of 200 concurrent Realtime connections in the Supabase limits page (read 2026-10-26).1 That average is misleading, because real load is skewed. Assume, as an illustration, a Zipf split in which project number k gets load proportional to 1/k.1
Under that assumption the busiest project carries about 10.2% of connections, which is about 5,108. The top 10 projects carry about 29.9%, the top 100 projects carry about 53.0%, and the quietest 5,000 carry about 7.1%.1 The same Supabase page lists caps of 200 (Free), 500 (Pro) and 10,000 (Team, and Pro without a spend cap). A single project at the 10,000 cap would hold 20% of the 50,000 total.1
Fleet size is the other number. With a database per tenant you patch and migrate 10,000 databases; with a pooled table you migrate one. If 90% of tenants are idle (an assumption), scale-to-zero or shared pools leave about 1,000 active computes against 10,000 always-on instances.1
| Quantity (illustrative unless noted) | Value |
|---|---|
| Average connections per project | 5 |
| Busiest project, Zipf split | about 5,108 connections, 10.2% |
| Top 100 projects, Zipf split | about 26,500 connections, 53.0% |
| Quietest 5,000 projects | about 3,541 connections, 7.1% |
| One project at the 10,000 cap | 20% of 50,000 |
| Databases to patch, silo vs pool | 10,000 vs 1 shared table |
| Active computes if 90% idle | about 1,000 |
| Realtime connection caps (Supabase, read 2026-10-26) | Free 200, Pro 500, Team 10,000 |
Text description of the diagram
- The busiest project carries about 10.2% of subscribers.
- The top 100 projects carry about 53.0% of subscribers.
The chart shows the illustrative split: the busiest project carries about 10.2% of connections, and the top 100 projects carry about 53.0%. The quietest 5,000 projects carry about 7.1%.1
Trade-offs and edge cases
No tenancy model wins every row, so the criterion decides. The comparison below follows the AWS and Microsoft documents cited above.
Text description of the diagram
- Silo gives the strongest isolation at the highest cost and complexity.
- Pool costs the least and isolates the least.
Silo gives the strongest isolation at the highest cost and complexity. Pool costs the least and isolates the least. Silo also makes cost attribution simple and removes noisy neighbors, and Azure adds that single-tenant deployments let updates roll out progressively, which lowers the chance of a system-wide outage. See deployment strategies for the rollout techniques.
Edge cases to name:
- Hot tenant. Move it from pool to its own stamp; the catalog makes that a data change, not a rewrite.
- Cold start. Scale-to-zero saves cost but delays the first request; a warm pool trades money for latency. Do not quote a cold-start time without measuring it.
- Per-tenant limits. Plans cap connections and message rates per project, so quotas belong in the control plane.
- Cache keys. A shared cache must include the tenant in every key; see the distributed cache design.
- Fleet drift. Thousands of separate databases need automated migration and a record of each one's version.
How to answer it in an interview
How would you design a multi-tenant provisioning system?
I'd start with the isolation spectrum: a database per tenant, a schema per tenant, or shared tables with row-level security. I'd pool small tenants for cost and give large ones their own stack, because row-level security isolates data but not load. A control plane runs an idempotent workflow: create resources, migrate, set quotas, start metering, register the tenant in a catalog. The catalog routes requests and lets me move a hot tenant. I'd roll changes out to a few tenants first.
The spoken structure: name the spectrum, pick per tier, say data isolation is not performance isolation, then the idempotent workflow, the catalog and the staged rollout.
Common mistakes
- "Multi-tenant means one shared database." (wrong) It is a spectrum, and some platforms run a single-tenant database per project on shared infrastructure. (right) "Tenancy is chosen per layer, from silo to pool."
- "Single-tenant stacks aren't SaaS." (wrong) AWS says they count when identity, onboarding, metering and operations are shared. (right) "A shared control plane makes siloed stacks one product."
- "Enabling row-level security isolates tenants." (wrong) Policies must exist, and they protect data, not performance. (right) "I add policies and separate limits for noisy neighbors."
- "Stamps remove noisy neighbors." (wrong) Only single-tenant stamps do. (right) "Multi-tenant stamps still need per-tenant limits."
- "Provisioning is one script." (wrong) A crash halfway leaves half a tenant. (right) "Idempotent steps plus a reconciler."
Follow-up questions
How would you design the multi-tenant Postgres provisioning system for fast spin-up and per-project isolation?
Keep a pool of pre-created, empty databases or computes, assign one to a new project through an idempotent workflow, apply the project's schema and credentials, and record it in the catalog. Isolation comes from a database or schema per project plus per-project quotas. Measure spin-up time yourself rather than quoting one.
How would you size a Realtime server for 50K subscribers across 10K projects?
Start from the average of 5 connections per project, then design for skew: a few projects hold most connections. Apply per-project caps like the plan limits above, shard subscribers across servers by project, and watch tail latency for the hot ones.
When should a tenant get its own database?
Give a tenant its own database or stamp when it needs stronger isolation, produces heavy load, or must be billed and rolled out separately. Small tenants stay pooled for cost.
Does row-level security stop a noisy neighbor?
No. It filters which rows a query sees, not how much processor time, memory or connection capacity a tenant uses. Use quotas, connection limits and, if needed, a separate stamp.
What makes provisioning safe to retry?
Each step is idempotent and keyed by the tenant, so running it twice leaves one result. A reconciler then repairs any half-finished tenant. The database interview questions page covers the transaction side.
How do you roll out a change to thousands of tenants?
Roll out progressively: a few tenants first, watch errors, then widen. Separate stamps make this easy because a bad release stays inside one stamp.
- Tenancy is a spectrum: silo gives the strongest isolation at the highest cost, pool the cheapest with the least.
- Row-level security isolates data, not load, so pooled tenants still need quotas.
- The control plane provisions through idempotent steps and meters each tenant.
- A tenant catalog maps tenants to stamps and lets you move a hot one.
- Average load hides skew; design for the busiest tenants.
Sources
- SaaS Tenant Isolation Strategies (silo, pool and bridge models) — Amazon Web Services whitepaper, 26 Oct 2026
- Multi-tenant architectures on AWS — Amazon Web Services guidance, 26 Oct 2026
- Multitenancy on Amazon RDS — Amazon Web Services whitepaper, 26 Oct 2026
- Architectural approaches for a multitenant solution — Microsoft Azure Architecture Center, 26 Oct 2026
- Tenancy models for a multitenant solution — Microsoft Azure Architecture Center, 26 Oct 2026
- PostgreSQL documentation: Row Security Policies — PostgreSQL Global Development Group, 26 Oct 2026
- PostgreSQL documentation: CREATE POLICY — PostgreSQL Global Development Group, 26 Oct 2026
- Supabase Realtime limits — Supabase documentation, 26 Oct 2026
- Supabase architecture — Supabase documentation, 26 Oct 2026
- Migration to v2 platform architecture (GitHub discussion 22135) — Supabase, 20 Mar 2024
- Neon: serverless Postgres (README) — Neon, 26 Oct 2026
- SaaS Tenant Isolation Strategies: pool isolation — Amazon Web Services whitepaper, 26 Oct 2026
- Multitenant SaaS database tenancy patterns — Microsoft Azure SQL documentation, 26 Oct 2026
- SaaS Tenant Isolation Strategies (PDF) — Amazon Web Services whitepaper, 26 Oct 2026
- Neon serverless Postgres: an analysis of the architecture — Jack Vanlightly, 15 Nov 2023
