How to Add Multi-Tenancy to an Existing SaaS Product
Most SaaS products don't start multi-tenant. They start as a single-customer tool that works, gets a second customer, then a third, usually held together with a customer_id column and good intentions. At some point the gap between that and real tenant isolation becomes a real business risk, not just a technical debt line item.
The signal it's time to fix this
If you can't confidently answer "can Customer A ever see Customer B's data" with a plain yes or no, that's the signal. Not when it becomes theoretically possible to imagine a breach, when someone with security diligence (an enterprise prospect, an auditor) asks the question directly and the honest answer is "probably not, but I'd have to check."
The retrofit path, roughly in order
- Audit every query path that touches tenant data. Not a sample, all of them. This is tedious and it's also the only way to know the actual scope of the problem before touching architecture.
- Pick an isolation model deliberately. Row-level isolation (a
tenant_idenforced at the query layer, ideally via database-level row security) is the most common retrofit path since it doesn't require splitting infrastructure. Separate schemas or databases per tenant are stronger isolation but a much bigger lift, usually only justified by specific compliance requirements. - Enforce isolation at the database layer, not just application code. Relying on every developer remembering to add a
WHERE tenant_id = ?clause is how isolation bugs happen. Row-level security policies (Postgres supports this natively) make the database itself refuse to return cross-tenant data, regardless of what the application code does. - Migrate incrementally, feature by feature, not all at once. A staged migration behind feature flags lets you validate isolation on lower-risk parts of the product before touching the core data model.
- Add automated tests specifically for isolation. Not just "does the feature work", but "can Tenant A's session ever retrieve Tenant B's data under any code path." This is the test suite that actually matters once isolation exists.
What this doesn't require
A full rewrite. The instinct to scrap everything and start over with "proper" multi-tenant architecture is understandable but usually wrong, most of the retrofit is enforcement and migration work on the existing data model, not a new one.
This is the same process behind our Multi-Tenant SaaS Platform Development work, and it usually starts with the architecture review in step one above, before any code changes.