TL;DR: Multi-tenant architecture is how one running copy of a SaaS product serves many customer companies while keeping each one's data, users and settings apart. For most new B2B products the right default is a shared database where every row carries a tenant ID, with isolation enforced by the database itself rather than by developers remembering a filter. Separate schemas or separate databases per tenant earn their extra cost only when a specific customer requirement demands them. The decisions that hurt later are rarely the database choice. They are the places tenant context gets lost: background jobs, caches, file storage, search indexes, analytics and AI features. Decide those before the first line of code, and test isolation like a feature.
Most product briefs we receive say "SaaS" and stop there. The pricing page gets a lot of thought, and we covered that in SaaS pricing and packaging, including the account model of organizations, members and roles. This article is the layer underneath: how the software keeps Company A out of Company B's data on every request, job and export. Get it wrong and the first symptom is usually a customer emailing a screenshot of someone else's records.
What a tenant actually is
A tenant is the unit of isolation: the boundary inside which data is shared and outside which it must never leak. In most B2B products the tenant is the customer organization, the company that signed the contract. Users belong to a tenant, and everything they create belongs to it too.
Two things complicate that picture. First, some products are nested. VoiceDash, our white-label portal for voice AI agencies, has agencies as tenants, and each agency has its own clients who log in and must see only their own dashboards. That is isolation at two levels, and both have to hold. Second, one person can belong to more than one tenant, like a consultant who works for two client companies. If your model assumes one user equals one tenant, that consultant becomes a support ticket and then a rewrite.
So the first decision is not technical: write down what the tenant is, whether there are tenants inside tenants, and whether a person can cross between them.
The three isolation models
Shared database, tenant ID on every row
All tenants live in the same tables, and every row carries the ID of the tenant that owns it. It is the cheapest to run and the easiest to migrate, because there is one schema to change, and it scales to many small tenants without per-tenant overhead.
The risk is that isolation now depends on every query including the right filter. One missed WHERE tenant_id = ? in a report endpoint and data leaks. The answer is to stop relying on developers to remember. Databases such as PostgreSQL support row-level security, where the database refuses to return rows outside the current tenant regardless of what the query asks for. Combined with a data access layer that sets the tenant on every connection, the safe path becomes the default path.
Schema per tenant
Each tenant gets its own set of tables inside a shared database. Isolation is clearer, and per-tenant backup and restore get easier. The cost shows up in operations: every schema change has to run across every tenant, connection pooling gets harder, and at a few thousand tenants the tooling starts to strain. It suits products with a moderate number of larger customers.
Database per tenant
Each tenant gets its own database, sometimes its own infrastructure. This gives the strongest isolation and the cleanest answers to enterprise questions about data location, encryption keys and deletion. It is also the most expensive to run and the slowest to roll changes across, since one release means a migration on every database.
Our default, and when we move off it
For a new product we start with a shared database, tenant ID on every row, and database-enforced isolation. We keep a path open to move a specific tenant onto dedicated infrastructure later, usually by keeping tenant routing in one place so the code does not care where a tenant's data physically lives.
Where tenant isolation actually breaks
Leaks rarely happen in the main tables. They happen wherever code runs without a request that says whose data this is.
Background jobs
A web request knows the logged-in user and their tenant. A job picked off a queue at 3am does not, unless the tenant ID was written into the job when it was queued. Every job should carry its tenant explicitly, and the worker should set the same isolation context a web request would.
Caches
A cache key like dashboard:summary is shared by every tenant who requests it. The second customer to load the page sees the first customer's numbers. Every cache key that holds tenant data must include the tenant ID,.
File storage
Uploaded files need a tenant prefix in their storage path and access checks on every download. Links that grant access to a file should be time-limited and scoped, not permanent public URLs that can be forwarded.
Search indexes and analytics
Search engines and analytics warehouses usually sit outside the main database, which means outside its row-level security. Tenant filtering has to be rebuilt there deliberately. A search box that returns another customer's document title in the suggestions is a leak, even if clicking it fails.
AI features
AI adds a new edge. A retrieval feature that searches across embedded documents must filter by tenant before anything reaches the model, and a model's context should never be assembled from more than one tenant's data. The boundary belongs in the retrieval layer, not the prompt; more in AI feature security.
Noisy neighbors and fair use
In a shared system, one tenant's heavy month is everyone's slow afternoon. A customer who imports a million records or triggers a huge report can starve the rest.
The defenses need designing in: Rate limits and quotas per tenant, not just per user. Separate queues or priority lanes so one tenant's bulk import cannot block another tenant's password reset email. Pagination and limits on every list endpoint. And per-tenant cost visibility. Every lecture recorded in LectureNotes AI, one of our own products, runs through transcription and summarization models that cost money each time, so knowing which accounts drive that cost is an operating requirement, not a nice-to-have. Tie these limits to the entitlement layer from your pricing model so a bigger plan can genuinely mean bigger limits.
Per-tenant configuration without forking the product
Sooner or later a large customer wants something different: a custom field, a different workflow step, their own branding, single sign-on with their identity provider. The temptation is a special branch or an if tenant == "BigCo" in the code. Both turn one product into several, and the maintenance bill compounds.
The better pattern is configuration as data. Branding, feature flags, custom fields, workflow options and SSO settings live as per-tenant settings the product reads at runtime. VoiceDash works this way by necessity, since every agency puts its own logo and domain on the same product. When a request cannot be expressed as configuration, that is a product decision about whether it should become a general feature, not a reason to fork.
Operations: migrations, backups and offboarding
Multi-tenancy changes some routine operations in ways that are easy to miss.
Migrations run against everyone at once in a shared model. A schema change that locks a large table locks it for every customer. Plan migrations to be backward compatible and run in steps, a discipline covered in our piece on software maintenance after launch.
Restoring one tenant is the request nobody plans for. A customer deletes half their data by mistake and asks for yesterday's version, but your backup is the whole database. Decide early how you would restore a single tenant without rolling back everyone else, even if the answer is a scripted export from a backup copy.
Offboarding and deletion need to reach everywhere the tenant's data went: main tables, files, search, analytics, logs, AI indexes and backups on their retention schedule. A tenant ID on everything is what makes this possible at all.
Enterprise questions to expect
If you sell upmarket, these will arrive in security reviews. Designing for them early costs little; retrofitting costs a lot.
- How exactly is our data separated from other customers' data?
- Can our data stay in a specific region?
- Do you support SSO and automated user provisioning from our identity provider?
- Can we have audit logs of who accessed what?
- How do you delete our data when we leave, and how do you prove it?
- Can we have dedicated infrastructure, and what does it cost?
Having clear, true answers also helps when investors or acquirers look under the hood, which we covered in technical due diligence. For products that handle money, such as Fyuel, our accounting platform for the fuel trade, tenant isolation is the whole product promise: one company seeing another's ledgers would end it. Our notes on building financial software go further on that kind of system.
Testing isolation like a feature
Isolation silently regresses: someone adds an endpoint, a job or a cache, and nothing fails until a customer notices.
The practical version: automated tests that create two tenants, populate both, then act as a user of one and attempt to read, list, search, export and download everything belonging to the other. Every new endpoint gets added to that suite. Row-level security gives you a second net under the first. We fold this into the broader approach in software testing and QA.
What this means for scope and cost
Multi-tenancy done properly is not a large line item if it is planned from day one. Done as a retrofit, after a product has launched as single-tenant or with filters scattered through the code, it becomes one of the more expensive migrations a team can face, because it touches every query on live customer data. If you are budgeting a first version, our guide to MVP development cost shows where this fits, and if you are still deciding whether to build at all, start with vertical SaaS: build vs buy.
A short checklist before you build:
- Define the tenant, any nested levels, and whether users can belong to more than one.
- Pick an isolation model and write down what would justify moving a tenant to dedicated infrastructure.
- Enforce isolation in the database, not only in application code.
- Put the tenant ID on every job, cache key, file path, search document and AI index.
- Add per-tenant limits, queues and cost visibility.
- Express customization as configuration, never as forks.
- Plan single-tenant restore and complete deletion.
- Write cross-tenant access tests and keep them growing.
Null Studio designs and builds multi-tenant SaaS products end to end, from data model and isolation to white-label configuration, billing and AI features, on the same team that ships and runs VoiceDash, LectureNotes AI and Fyuel. Book a demo and we'll walk through how your product's tenants should be structured before anything gets built.