The decision you make before your first customer
Multi-tenancy is how SaaS platforms serve multiple customers from a single codebase. The architecture you choose at the start determines how much your infrastructure costs, how secure your customers' data is, and how much work a large enterprise customer costs you.
Get this wrong and you rebuild it at the worst possible time: when you are scaling.
The three models
Model 1: Shared database, shared schema
Every tenant's data lives in the same tables. A tenant_id column separates their records.
How it works: Every table has a tenant_id. Every query is scoped to that tenant_id. Row-level security or application-level filtering prevents data leakage.
The advantages:
- Cheapest to operate (one database, one schema)
- Easiest to maintain (one migration applies everywhere)
- Simplest to build initially
The risks:
- A bug in tenant filtering exposes one customer's data to another — catastrophic
- One customer's query volume can degrade performance for all customers
- Large enterprise customers with strict data residency requirements cannot be accommodated
- Compliance requirements (HIPAA, SOC2, GDPR) are harder to satisfy
Right for: B2C or SMB SaaS where tenants are many, small, and not in regulated industries.
Model 2: Shared database, isolated schema
Every tenant gets their own schema within the same database. Tables are the same structure, but data is fully separated at the schema level.
How it works: When a new tenant signs up, a schema is provisioned for them. Queries route to the correct schema.
The advantages:
- Strong data isolation without separate databases
- Easier compliance story (data is separated, not just filtered)
- Migrations still apply to all schemas (automated, but more complex)
The risks:
- Database size and connection limits become constraints at scale
- Migration complexity grows linearly with tenant count
- Performance problems from one tenant can still affect others (shared compute)
Right for: SMB to mid-market SaaS with moderate compliance requirements. The sweet spot for most B2B SaaS platforms under 500 tenants.
Model 3: Isolated databases per tenant
Every tenant gets their own database instance.
How it works: Tenant onboarding provisions a new database. A routing layer maps tenant requests to the correct database.
The advantages:
- Complete data isolation — no shared attack surface
- Can offer different SLAs and regions per tenant
- Meets the most stringent compliance requirements
- Performance for one tenant is fully independent of others
The risks:
- Dramatically more expensive to operate
- Migrations must be applied to every database — automation is essential
- Connection pool management becomes complex at scale
Right for: Enterprise SaaS with regulated industries (healthcare, finance, government), large deals where data residency matters, or platforms where a breach between tenants would be existential.
The hybrid approach
Most mature SaaS platforms end up hybrid: small/free-tier customers on a shared schema, paying customers on isolated schemas, enterprise customers on isolated databases. The routing layer handles the complexity.
This is the architecture to design for even if you start simpler. Build the routing abstraction early, even if all traffic goes to one database initially. Migrating later is possible but expensive.
The questions that drive the decision
Before choosing your model, answer:
What is your target customer segment?
Consumer and SMB: shared schema. Mid-market B2B: shared database, isolated schema. Enterprise: isolated databases.
Are any of your target customers in regulated industries?
Healthcare, finance, legal, and government customers will ask about data isolation before they sign. If you cannot provide a clean answer, you lose the deal.
What is your expected customer count in 24 months?
1,000+ customers on isolated databases is operationally complex and expensive. 50 enterprise customers on shared schema is a compliance risk. Match the model to the scale.
What is the blast radius if tenant data is exposed?
If the answer is "existential," err toward isolation. The cost of the right architecture is fixed. The cost of a data breach is open-ended.
The implementation details that actually matter
Whatever model you choose, these implementation decisions have outsized consequences:
Tenant context propagation. Every layer of the stack must know which tenant is active: HTTP layer, service layer, database layer. If any layer strips this context, you have a potential leak. Use middleware that sets and verifies tenant context on every request.
Soft-delete everywhere. Never hard-delete tenant data. Use deleted_at timestamps. When a customer churns or disputes a claim, you need to recover their data.
Audit logging per tenant. Who changed what, when, from what IP. Required for compliance, invaluable for debugging.
Tenant-scoped rate limiting. One badly-behaved customer should not be able to degrade your platform for everyone else. Rate limiting at the tenant level is infrastructure, not a feature.
These are not optimizations. They are the foundation. Build them on day one.