Designing Multi-Tenant SaaS Architecture: What Actually Matters
Every multi-tenant SaaS product eventually has to answer the same question: how isolated should one customer's data be from another's? Get the answer wrong early and it's one of the more expensive things to unwind later.
The three real options
At the database level there are really three shapes this can take: a fully separate database per tenant, a shared database with a tenant_id column on every table, or a middle ground using separate schemas within one database. Separate-database-per-tenant gives the strongest isolation and the easiest "delete this customer's data" story, but it doesn't scale operationally past a certain tenant count — migrations, connection pooling, and monitoring all get harder linearly with tenant count. Shared-database-with-tenant-id is the cheapest to operate and scales the furthest, but it puts the burden of correctness entirely on application code: one missing WHERE tenant_id = ? clause is a data leak, not a bug report.
For most products in the early-to-mid stage, we lean toward shared database with row-level tenant scoping enforced at the query-builder or ORM level, not hand-written per query — Postgres row-level security policies are a reasonable belt-and-suspenders addition once the product has real customers with real compliance expectations.
Where the real scalability budget goes
Multi-tenancy problems rarely show up as "the database is too slow." They show up as one large tenant's usage pattern degrading performance for every other tenant sharing the same resources — a single customer running an expensive report query, or a burst of webhook traffic from one integration partner. This is where connection pooling limits, per-tenant rate limiting, and background job queue prioritization earn their keep, well before you need to think about sharding.
Caching and message queues, added when measured
Redis-backed caching and a message queue for async work are both good defaults, but the mistake is reaching for them before profiling shows they're needed. A cache in front of a query that's already fast just adds a new thing that can go stale. The useful order of operations is: measure, find the actual bottleneck, then decide whether a cache, an index, or a queue is the right tool for that specific bottleneck.
The part that's hard to retrofit
Tenant isolation strategy and the primary key strategy for tenant-scoped tables are the two decisions that are genuinely expensive to change after you have production data. Everything else — caching layers, queue choice, even parts of the API surface — can be refactored incrementally. Get those two right at the start, and the rest of the architecture has room to evolve as the product actually grows.