Introduction
Multi-tenancy is the architectural decision that shapes nearly everything else in a SaaS product — cost, security posture, and how painful scaling will eventually be. Getting it right early avoids an expensive migration later.
Database-Per-Tenant
Each customer gets an entirely separate database. This offers the strongest isolation and the simplest mental model for compliance-heavy industries, but at meaningful infrastructure cost and operational overhead once you have hundreds of tenants, since every migration has to run against every database.
Schema-Per-Tenant
A middle ground: one database, separate schemas per tenant. This reduces some operational overhead versus fully separate databases while still offering reasonable isolation, though it doesn't eliminate the migration-fan-out problem entirely.
Row-Level Security
The most common modern approach: one shared schema, every table carries a tenant_id, and the database enforces row-level security so tenants can never see each other's rows even if application code has a bug. This is the cheapest to operate at scale and the easiest to run migrations against, at the cost of a slightly higher bar for getting the security policies right from day one.
Making the Call
For most SaaS startups, row-level security with PostgreSQL is the right default — it's cost-efficient and scales well operationally. Reach for schema or database-per-tenant only when a specific customer segment (enterprise, healthcare, finance) requires the stronger isolation guarantee as a contractual or compliance requirement.
Conclusion
This decision is expensive to reverse once you have real customer data in production. Default to row-level security unless you have a concrete reason not to, and revisit it only for specific high-compliance customers.
Frequently Asked Questions
What is row-level security in the context of multi-tenancy?+
It's a database feature where every table includes a tenant_id column, and the database itself enforces that tenants can only see their own rows — even if application code has a bug, the database layer prevents cross-tenant data leaks.
Is database-per-tenant ever worth the extra cost?+
Yes, particularly for compliance-heavy industries like healthcare or finance where a specific customer contractually requires full data isolation. For most SaaS products without that requirement, it adds cost without a corresponding benefit.
Can I switch multi-tenancy models later?+
It's possible but disruptive — it usually requires a significant data migration once real customer data exists. Choosing the right model early avoids this costly rework.
