The one bug that ends SaaS companies
A query missing its tenant filter, showing one customer another customer's data. It is a single forgotten WHERE clause, it is career-defining for the company, and it is entirely preventable by enforcing scoping where it cannot be omitted.
These are the architecture decisions that are cheap now and extremely expensive to change once you have customers.
The three tenancy models
| Shared DB, tenant column | Schema per tenant | Database per tenant | |
|---|---|---|---|
| Isolation strength | Logical | Stronger | Strongest |
| Operating cost | Lowest | Moderate | Highest |
| Migrations | One run | Per schema | Per database |
| Backup / restore per tenant | Harder | Easier | Easiest |
| Cross-tenant analytics | Easy | Harder | Hardest |
| Scales to many tenants | Thousands+ | Hundreds | Dozens |
| Suits | Most SaaS | Compliance needs | Enterprise contracts |
Choose shared-database unless you have a specific reason not to. Teams frequently pick stronger isolation early "to be safe", then discover that running migrations across four hundred schemas is a genuine operational burden. Isolation you do not need is cost you pay every deployment.
Enforcing tenant scoping
The critical implementation detail. Application-level discipline is not sufficient — someone will eventually write a query without the filter.
- Default scoping at the data layer. Your ORM or query builder should apply the tenant filter automatically, requiring explicit opt-out for the rare cross-tenant query.
- Row-level security in the database where your engine supports it — a second line of defence beneath the application.
- Tenant context set once per request, from the authenticated session, never from user input.
- Automated tests that attempt cross-tenant access and assert failure.
- Audit query paths periodically for anything bypassing the default.
Every SaaS company that has leaked data across tenants had developers who knew to add the filter. The failure is architectural, not personal — which is why the fix has to be architectural too.
Decisions that are hard to reverse
Tenant identifier design
Use an opaque identifier, not a sequential integer. Sequential IDs leak customer count and invite enumeration attempts. This costs nothing to get right and is awkward to change later.
What you record for billing
If you might ever charge by usage — seats, API calls, storage, records processed — instrument it from day one. Usage data cannot be backfilled, and the decision to introduce usage-based pricing is frequently made after growth.
Customer data deletion
Can you completely remove one tenant's data, including from backups, logs, caches and search indexes? Regulations require it and customers ask. Designing it in is straightforward; retrofitting is not.
Per-tenant configuration
Feature flags, limits, branding and settings scoped per tenant. Almost every SaaS needs this eventually, and adding the concept later means touching everything.
Build per-tenant feature flags in version one. They cost little upfront and they enable everything afterwards — beta programmes, staged rollouts, enterprise-only capability, and disabling a broken feature for one customer without a deployment.
The noisy neighbour problem
Shared infrastructure means one tenant can degrade service for others:
- Rate limit per tenant, not just globally.
- Cap expensive operations — large exports, bulk imports, complex reports.
- Queue heavy work with per-tenant fairness rather than first-come processing.
- Monitor resource consumption by tenant so you can identify the cause of a slowdown.
- Consider a separate worker pool for the largest customers.
Operational considerations
| Requirement | Design implication |
|---|---|
| Restore one tenant's data | Hard in shared DB — plan the approach |
| Export a tenant's data | Build it; customers will ask |
| Migrate a tenant to dedicated infra | Design the path before selling the tier |
| Support impersonation | Essential for support, needs strict audit |
| Per-tenant metrics | Needed for billing and for diagnosis |
Support impersonation deserves specific attention — your team will need it to help customers, and it is a powerful capability that must be logged, time-limited, and visible to the customer.
When to offer dedicated infrastructure
Some enterprise customers will require it. Treat it as a premium tier priced for the real cost:
- Separate deployments mean separate upgrade cycles.
- Separate monitoring and incident response.
- Configuration drift between instances becomes a real risk.
- Your release process must handle multiple environments.
The infrastructure bill is the smallest part of that cost. The operational burden is the rest, and it grows with every dedicated customer.
Designing a multi-tenant system? Tell us your expected tenant count and isolation requirements. See our web application service, SaaS architecture guide, and MVP cost and scope.