The honest cost of multi-tenant SaaS architecture
Multi-tenant SaaS gets pitched as the obvious right answer for any B2B product. The trade-offs are real, the cost compounds quietly, and choosing wrong adds twelve months to your roadmap.
The default has costs
Most early-stage SaaS founders are told that multi-tenant is the right architecture by default. There is a kernel of truth — multi-tenancy makes operations cheaper at scale and lets one fix benefit every customer simultaneously. But the trade-offs that come with it are routinely understated, and they compound silently for years until they show up as either a forced rewrite or a competitor that can move faster than you can.
We have built and operated both shared-tenant and dedicated-tenant SaaS for our clients. This is what the trade-offs actually look like.
The shared-tenant tax
Every line of code in a multi-tenant system has to answer the question "whose data is this?" — at the query layer, the cache layer, the background-job layer, the logging layer, and the metrics layer. Get any of those wrong even once and you have a cross-tenant data leak, which in our experience is one of the few things that can actually end a B2B SaaS company overnight.
The practical consequences:
- Every query needs a tenant predicate. This sounds trivial until you have a developer write a one-line bug-fix that forgets the WHERE tenant_id filter. We have seen this in production. The fix is row-level security at the database, but RLS in Postgres has real performance implications and most teams discover this after they have already shipped the wrong way.
- Every cache key needs to be tenant-scoped. A typo here is a cross-tenant cache leak. The fix is a wrapper layer around your cache library, which someone has to build, maintain, and convince every new engineer to use.
- Every background job needs to remember which tenant it is for. Easy when the job runs in response to a tenant action. Hard when the job is a periodic sweep — now you need a fan-out pattern that spawns one sub-job per tenant, queues them carefully, and aggregates results.
- Every external integration needs per-tenant credentials. OAuth tokens, SP-API keys, Stripe accounts, webhooks — multiplied by tenant count. The credential management layer is its own engineering problem.
None of these are insurmountable. All of them are real engineering work that does not exist in a single-tenant world.
The dedicated-tenant tax
The opposite extreme — every customer gets their own database, their own background workers, their own deployment — has its own tax. Now you are running N copies of your stack instead of one. Schema migrations have to roll out across N tenants safely. Bug fixes have to be deployed N times. Cost scales linearly with customer count rather than sub-linearly.
For most B2B SaaS at the SMB scale, the per-tenant cost of a dedicated stack is uneconomic. For enterprise SaaS where each customer is paying $50k+/year, the per-tenant cost is fine and the simplicity buys you back the engineering time the multi-tenant tax was eating.
The hybrid that often wins
The pattern we recommend most often, especially for B2B SaaS in the $1k-$10k ACV range, is what we call shared compute, shared schema, but per-tenant data isolation enforced at the row level with hard guardrails. Concretely:
- Single Postgres database, every tenant-scoped table has a tenant_id column with row-level security policies. - Single set of background workers, but jobs are tagged with tenant_id and the worker pool has rate limits per tenant. - Single deployment, but feature flags allow per-tenant overrides for rollout staging. - Hard guardrails: integration tests that explicitly try to cross tenants and verify they get rejected.
This is not the cheapest possible architecture, but it is the one that scales from 50 customers to 500 customers without a rewrite — which is the relevant scaling question for most SaaS companies.
When to choose dedicated
Three situations make us recommend dedicated-tenant from day one:
1. Compliance requires data residency. EU customer needs data in EU? US customer needs data in US? Dedicated wins immediately. 2. Customer expects custom workflows. If your product allows per-customer customization of the underlying schema or business logic, multi-tenant is impossible to maintain. 3. Single-customer ACV exceeds engineering cost of dedicated stack. If a customer is paying $200k/year, running them on their own dedicated stack is a rounding error.
What we tell new clients
We do not lead with "you should be multi-tenant" or "you should be dedicated". We start with the customer profile and the compliance landscape and reverse-engineer the architecture from there. Most of the time we end up at hybrid. Sometimes we end up at dedicated. Almost never do we end up at pure shared-everything multi-tenant.
The wrong call here adds twelve months to the eventual rewrite. The right call is worth thinking about for a week.