The pattern
One application instance. One database. Multiple customers. Each customer's data is isolated by a tenant_id on every table, enforced by row-level security (RLS) policies. Logging in as customer A means you see only their workspace data — even at the database query level.
The alternative is single-tenant: one deployed instance per customer. It exists for enterprise compliance reasons (HIPAA, certain financial regs) but is dramatically more expensive to operate and slower to ship to.
What "doing it right" means
Multi-tenant done wrong looks like a single-tenant app with a tenant_id added later. Half the queries forget to filter by tenant, leaks happen, and security audits fail. The fix involves rewriting most of the data access layer.
Multi-tenant done right from day one:
- Tenant column on every table that holds tenant data
- Row-level security policies enforced by the database (Postgres RLS is the cleanest)
- Application code never sets tenant_id manually — it comes from the session
- All tests run with a multi-tenant fixture, not single-user
- Cross-tenant operations (admin views, billing aggregation) explicitly bypass RLS with a clear flag
When to ship multi-tenant from day one
Always, for B2B SaaS. The cost of doing it from commit one is maybe 4–6 hours of architecture work upfront. The cost of bolting it on after 6 months of single-tenant code is several weeks.
Cost implications
The first multi-tenant tier in our MVP cost sheet starts at $20K. Below that price point we deliberately don't include multi-tenant — it's the architectural decision that locks in the most future cost if rushed.
