- Shared schema with a tenant_id column and Postgres RLS is the default for most SaaS MVPs because migrations run once and cost stays flat as tenants grow.
- Database per tenant pays off when you have a small number of large customers with hard isolation, residency, or noisy-neighbor requirements.
- The real cost of database per tenant is not storage, it is running migrations, backups, and connection pools across N databases.
- You can start shared schema and move your biggest tenant to its own database later, but only if tenant_id is in every table from day one.
Your first enterprise prospect sends over a security questionnaire and one line stops you cold: "Confirm that our data is stored in a dedicated database instance." You have 40 customers on a shared Postgres cluster with a tenant_id column and RLS policies, and it has been working fine. Now you are pricing out what it costs to give one customer their own database, and whether that decision quietly breaks your migration pipeline. This is the moment most founders realize multi-tenancy is not a schema detail, it is a product decision with a bill attached.
Devs & Logics builds SaaS MVPs, web platforms, mobile apps, and AI-powered products for US startups and enterprises, and tenant isolation is one of the first architectural forks we walk founders through. If you want the wider picture before this decision, our complete guide to multi-tenant SaaS database architecture covers the models above and below this one. Here is the cost and scaling reality behind each.
What Is the Difference Between Database per Tenant and Shared Schema?
Database per tenant gives every customer their own physical database, while shared schema puts all tenants in one database separated by a tenant_id column. The difference shows up in isolation, migration cost, and how you handle a single customer who outgrows everyone else.
In a shared schema model, one Postgres database holds every tenant's rows. A customers table has a tenant_id foreign key, an orders table has a tenant_id, and so on. Every query filters on that column, and Row Level Security policies enforce it at the database layer so a missing WHERE clause does not leak data. You run one migration and every tenant gets the new column at the same moment.
In database per tenant, tenant A lives in db_tenant_a and tenant B lives in db_tenant_b. Your application resolves the tenant from the request, looks up the connection string, and opens a pool to that specific database. There is no tenant_id column because the database boundary is the tenant boundary. Isolation is physical, not logical.
There is a middle option worth naming: schema per tenant, where one Postgres instance holds many schemas and each tenant gets its own. It gives you cleaner separation than shared schema without a database per customer, but it still multiplies migrations and it makes cross-tenant analytics awkward. Most teams either go shared schema or full database per tenant, and the schema-per-tenant path tends to get abandoned once the migration tooling gets painful.
The decision is not about which is more modern. It is about how many tenants you expect, how large the largest one gets relative to the smallest, and whether a contract or regulator forces physical separation.
Database per Tenant vs Shared Schema: Cost and Scaling Comparison
Shared schema keeps infrastructure cost roughly flat per tenant, while database per tenant adds a fixed cost per customer for compute, storage, and connection overhead. That fixed cost is small at 10 tenants and painful at 10,000.
Storage is the least interesting line item. A small tenant's data might be a few hundred megabytes, which is nearly free either way. The cost that actually moves your bill is operational: how many databases you have to migrate, back up, monitor, and connect to. For a fuller breakdown of what drives MVP budgets, see what a SaaS MVP actually costs in 2026.
| Dimension | Shared Schema | Database per Tenant |
|---|---|---|
| Isolation model | Logical, enforced by tenant_id plus RLS | Physical, separate database per customer |
| Migration cost | One migration for all tenants | One migration per database, N times |
| Connection overhead | One pool, shared across tenants | One pool per tenant, or a router with strict limits |
| Noisy neighbor risk | Real, one heavy tenant can slow others | Contained, a heavy tenant only hurts itself |
| Per-tenant cost curve | Roughly flat as tenants grow | Fixed cost per tenant, scales with customer count |
| Cross-tenant analytics | Simple SQL across one dataset | Requires ETL into a warehouse or federated queries |
The connection overhead row is the one that surprises people. Postgres does not love thousands of active connections, and each database per tenant needs its own pool. At 50 tenants you can run a pool per tenant on a decent instance. At 500 tenants you are either paying for a connection pooler like PgBouncer in front of every database or building a routing layer that opens connections lazily. That routing layer is real engineering work, and it is the tax nobody puts in the original estimate.
On the shared side, the cost curve is boring in the best way. One database, one pool, one migration. You scale vertically until you cannot, then you shard by tenant_id ranges or move your largest tenants out. Boring is cheap.
How Shared Schema Works in Practice: tenant_id, RLS, and Indexes
Shared schema works when every tenant-scoped table carries a tenant_id, every query filters on it, and Postgres Row Level Security enforces it at the database layer. Skip any of those three and you have a data leak waiting to happen.
Start with the schema. Every tenant-scoped table gets a tenant_id column, indexed, and ideally the first column in your composite indexes. A query like SELECT * FROM invoices WHERE tenant_id = $1 AND status = 'open' uses an index on (tenant_id, status) and stays fast even with millions of rows across thousands of tenants. Get the index order wrong and you scan the whole table for one customer.
Then enforce it in the database, not just the application. RLS policies look like this:
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY; CREATE POLICY tenant_isolation ON invoices USING (tenant_id = current_setting('app.tenant_id')::uuid);Your application sets app.tenant_id on the connection at the start of every request, and Postgres refuses to return rows from any other tenant. This matters because application-level filtering fails the moment someone writes a raw query, adds a background job, or forgets a WHERE clause during a refactor. RLS is the backstop.
The tradeoff is that RLS adds a small per-query cost and it can confuse ORMs that generate their own SQL. Prisma, for example, does not set session variables for you, so you wrap queries in a transaction that runs SET LOCAL app.tenant_id first. It is a pattern, not a blocker, and we have shipped it on B2B products including how we shipped a fintech B2B MVP in seven weeks.
The other shared schema risk is the noisy neighbor. One tenant running a heavy report can hold locks or saturate CPU for everyone. You mitigate it with per-tenant rate limits, read replicas for reporting queries, and statement timeouts so a runaway query dies instead of dragging the cluster down. None of that is free, but it is cheaper than running a database per customer before you have the customers to justify it.
How Database per Tenant Works in Practice: Routing, Migrations, and Pools
Database per tenant means your app resolves the tenant to a connection string at request time, then runs migrations and backups across every database. The hard part is not creating the databases, it is keeping them in sync as your schema evolves.
Routing starts with a lookup. Your request carries a tenant identifier, usually from a subdomain, a JWT claim, or a header. You map that to a connection string stored in a control-plane database, then hand the connection to your data layer. In Node.js with a Postgres client, that looks like a per-tenant pool registry keyed by tenant id, with a max pool size small enough that 200 tenants do not exhaust your connection limit. This is exactly the kind of deployment plumbing we handle in DevOps and cloud setup for multi-tenant deployments.
Migrations are where database per tenant earns its reputation. A single migration file has to run against every database, and they will not all succeed at the same time. A long-running ALTER on tenant 47 can time out while tenants 1 through 46 are already on the new schema. Now you have tenants on different schema versions and your application code has to tolerate both, or you block the deploy until every database catches up.
The pattern that works: run migrations through a job queue, one database at a time, with a version table per database and a retry policy. Track which tenants are behind. Never assume a migration succeeded just because the command exited. If you skip this, a single failed migration can leave you debugging a tenant that is three versions behind the rest, which is the operational reality behind the honest tradeoff below.
Backups and restores also multiply. A shared schema restore is one operation. A database per tenant restore is N operations, and if a customer asks you to restore their data to a point in time, you need per-database snapshots and a tested restore runbook. That runbook is the difference between a five-minute recovery and a five-hour one.
Compliance, Data Residency, and Noisy Neighbors
Database per tenant makes data residency and customer-specific retention policies easier to prove, while shared schema relies on application and RLS controls. Neither is automatically compliant, but isolation is easier to demonstrate in a security review.
If a customer in the EU needs their data to stay in an EU region, database per tenant lets you place that database in an EU region and point the router at it. Shared schema can do the same thing with regional clusters and routing, but you are now splitting your tenants across regions inside one logical model, which is more moving parts. Physical isolation is simply easier to explain to an auditor.
On retention, a customer who wants their data deleted on a schedule is a DELETE with a WHERE clause in shared schema, or a full database drop in database per tenant. The drop is cleaner to prove. The tradeoff is that the drop is also irreversible, so you want soft deletes and a grace period before you actually drop anything.
Noisy neighbors cut the other way. Shared schema concentrates risk: one tenant's bad query affects everyone. Database per tenant contains it, but you pay for that containment with the migration and connection overhead above. If your customers are large enough that a single one can spike CPU, isolation starts to pay for itself.
One honest limitation: a shared schema with RLS can satisfy SOC 2 and GDPR requirements when the controls are documented and tested, but the agency itself is not certified by building it. Compliance is about your processes, your access controls, and your evidence, not just the schema. Do not let anyone tell you a database topology is a certificate.
Which Should You Choose for Your SaaS MVP?
Start with shared schema and a tenant_id on every table unless a specific customer contract or regulation forces physical isolation. You can split a large tenant into its own database later, but you cannot retrofit tenant_id into a schema that never had it.
The rule we give founders: shared schema is the default, database per tenant is the exception you earn. If your first ten customers are small or mid-market, shared schema with RLS gets you to launch faster and cheaper. If your first customer is an enterprise with a dedicated-database clause in the contract, build the router from day one and accept the operational cost.
The migration path matters more than the starting point. If every table has tenant_id from the first commit, moving a large tenant to its own database is a data copy and a routing change, not a rewrite. If tenant_id is missing, you are looking at a schema migration across live customer data, which is the kind of project that eats a quarter.
That is the honest tradeoff: database per tenant is not the safe default people assume it is. At 5 to 20 tenants it feels clean, but once you cross a few hundred databases you are running migrations, backups, and connection pools across all of them, and a single failed migration can leave tenants on different schema versions. For most MVPs under 1,000 tenants, shared schema with tenant_id and RLS is cheaper to run and easier to ship, and the isolation gap is smaller than the operational tax you pay for physical separation. Pick database per tenant when a contract, a regulator, or a genuinely huge customer forces it, not because it sounds more enterprise.
Is database per tenant more expensive than shared schema?
Yes, database per tenant carries a fixed cost per customer that shared schema does not, and that cost grows with tenant count rather than data volume.
Each database needs its own connection pool, its own migration run, its own backup, and its own monitoring. At ten tenants that overhead is trivial. At a few hundred it becomes a meaningful engineering and infrastructure line item, because you are paying for N of everything instead of one. Shared schema keeps those costs flat, which is why it wins on cost for most SaaS products below enterprise scale.
Can I migrate from shared schema to database per tenant later?
Yes, if tenant_id is on every table from day one, and it is painful if it is not.
The migration itself is a data export for the target tenant, a load into the new database, and a routing change so that tenant's requests hit the new connection. With tenant_id in place, that is a copy job and a config change. Without it, you are reconstructing ownership from joins and application logic across live data, which is where these projects go sideways.
Does shared schema with RLS satisfy SOC 2 or GDPR requirements?
It can, as long as the controls around it are documented and tested, because the schema model is one input among many.
Auditors look at access control, encryption, logging, incident response, and evidence that your isolation actually holds. RLS policies that are covered by tests and reviewed in code help. A shared database with no RLS and no tests does not, regardless of how you describe it. Building HIPAA-aware or GDPR-ready software is about the controls you ship, not a badge on the architecture diagram.
How many tenants can a single Postgres database handle?
It depends far more on query patterns and index design than on a magic tenant number, and well-indexed shared schemas routinely handle thousands of small tenants.
The practical limits are table size, index bloat, and connection count, not tenant count itself. If every query filters on an indexed tenant_id and you keep hot tables vacuumed and analyzed, a single Postgres instance can serve a large tenant base. The moment you see full table scans, missing tenant_id indexes, or connection exhaustion, that is your signal to shard or split, not a fixed row count.
The Short Version
Shared schema with tenant_id and RLS is the right default for most SaaS MVPs in 2026: one migration, flat cost, and isolation that holds up in a security review when you test it. Database per tenant is a deliberate choice for a small number of large customers with hard isolation or residency requirements, and you should only pay its operational tax when a contract or regulator forces it.
Whichever you pick, put tenant_id on every table from the first commit. That single decision keeps the door open to split a large tenant later without rewriting your schema under live data.
If you want this modeled correctly before you write the first migration, SaaS MVP development with the right tenant model from day one is where we start, and you can grab the free MVP launch playbook to pressure-test the rest of your architecture before you build.