Architecture
Almost every SaaS MVP ends up asking: how do we keep customer data apart? The answer is often either "we'll think about it later" (expensive) or "we'll build enterprise isolation from day one" (also expensive). Both extremes get something right — and both get the timing wrong.
Multi-tenant isn't one architecture. It's a family of choices about data, auth and operations. This is the decision sequence we use ourselves when we build or refactor a product.
TL;DR
Key takeaways
- Start with organisation as a first-class concept — even in a single-tenant MVP. It's cheap early and expensive late.
- Shared database + Row Level Security in Postgres is the right default for most B2B SaaS.
- Schema- or database-per-tenant is for compliance, noisy neighbours, or customers who contractually require it — not for vanity.
- UI filters are not isolation. The guarantee must live in the database or an equivalent authoritative layer.
- SSO, audit logs and "organisations inside organisations" can wait until a concrete customer requires them.
What "tenant" actually means
A tenant is the boundary you sell and isolate against — typically a business customer (organisation). Inside it you have users, roles and data. Outside it, nothing may leak. That sounds banal until queries start joining across tenants, webhooks lack org scope, or a support admin sees the wrong customer data because a filter was missing in the UI.
So good multi-tenant doesn't start with Kubernetes namespaces. It starts with a data model where almost every business table has an `organization_id` (or equivalent), and where the application never trusts the client to "remember" which org it's in.
If your MVP only has one customer in production, you should still model the organisation. You don't need three isolation layers — you need one consistent one.
Shared database vs. stronger isolation
Shared database (with RLS)
One Postgres, tenant scope on every row, policies that enforce access.
- Fastest to build and migrate
- One pipeline, one schema, one backup strategy
- RLS as a safety net under application mistakes
- Requires discipline in queries and tests
- Some enterprise customers will require more later
Schema- or DB-per-tenant
Stronger isolation — and significantly more operations.
- Clearer compliance story for individual customers
- Noisy workloads affect neighbours less
- Migrations and migration tooling become a product of their own
- Observability and connection pooling get more complex
- Only worth it when a concrete requirement or risk justifies it
When do we choose what?
Read the left as your situation — the right as the typical recommendation.
Your situation
B2B SaaS MVP with few customers and standard data requirements
Our recommendation
Shared DB + organisation on every row + RLS. Ship the product.
Your situation
You need a team member to see only their own department within the customer
Our recommendation
Roles and scopes on top of the org model — still shared DB.
Your situation
A design-win requires data residency or contractual isolation
Our recommendation
Dedicated DB/schema for that tenant — preferably as an exception, not the default.
Your situation
One customer generates disproportionate load
Our recommendation
Query and cache work first; then consider dedicated resources for that tenant.
Your situation
You're considering "a database per customer" from day one "to be safe"
Our recommendation
Don't — unless compliance already requires it. You're buying operations you don't need.
Your situation
You're single-tenant today and need to open for more customers
Our recommendation
Refactor to org-scope + RLS before you scale sales. Cheaper than cleaning up after leak risk.
The sequence we recommend
Do things in this order. Don't jump to isolation level three before one and two are in place.
- 01
Organisation as the core model
Every business entity belongs to an organisation. The session knows the active org. No "implicit global" data except platform admin.
- 02
Auth and membership
Users belong to organisations via membership with roles. Invitations, removal and switching active org are first-class flows.
- 03
Database enforcement (RLS)
Policies that ensure even a bug in application code can't leak across tenants. Test the policies the way you test features.
- 04
Observability per tenant
Logs and metrics with org id, so you can debug and later allocate cost without guessing.
- 05
Isolation exceptions
Only when a concrete requirement appears: dedicated schema/DB, separate region, or customer-managed keys — as a deliberate add-on.
What can safely wait
SSO (SAML/OIDC via WorkOS, Auth0 or similar) can wait until the first customer that requires it in the contract — if your auth model already has organisation and external ids as concepts. Building SSO "because enterprise" without a pipeline of enterprise deals is speculation.
Hierarchical organisations (holding → subsidiaries → teams) can wait. Most products get far with flat orgs and groups/roles inside. Hierarchy is hard to reverse correctly; wait for the concrete need.
Per-tenant feature flags, custom domains and white-label are product choices — not isolation choices. They're easier on top of a clean org model, and almost impossible on top of a mess of global tables.
Questions we get again and again
Is Row Level Security enough?
For most B2B SaaS: yes, as a database guarantee — combined with the application always setting the right tenant context. RLS doesn't replace good auth or authorization in the app; it's the safety net underneath. You still need to test that policies cover new tables.
How do we test that data doesn't leak?
Automated tests that sign in as a user in org A and attempt to read org B's data — both via the API and directly via the database role the app uses. Add it to CI. Manual spot checks aren't a strategy when you add tables every sprint.
What about Supabase, Clerk or Auth0?
They solve auth and partly org models. They don't automatically make your business tables correctly scoped. Pick them for speed on login and membership — but still own your data-isolation model in the database.
When should we split to database-per-tenant?
When a contractual requirement, a compliance requirement, or a concrete performance/noise problem makes the shared model more expensive than a split. Not when an investor mentions "enterprise-ready". A split is an operations decision with migration cost — take it with open eyes.
Can we migrate from single-tenant later?
Yes, but the price grows with data volume and number of integrations. The earlier you have organisation on the rows, the more "migration" is an extension. The longer you wait, the more it's a rewrite of assumptions across the codebase.
Scaling to more customers?
Get an honest assessment of your tenant model.
We'll look at data model, auth and risk — and say whether you should tighten RLS, wait, or actually isolate a tenant.