Multi-Tenant SaaS Isolation Without the Tax
Shared databases vs. siloed tenants, row-level security, and how we choose isolation models for compliance-heavy clients.
Isolation is a spectrum
Pooling every tenant in one schema is cheapest operationally and riskiest for noisy neighbours and compliance reviews. Dedicated databases per tenant invert that trade-off. Most B2B products land somewhere in between: shared compute, careful data boundaries, and selective silos for enterprise contracts.
We start from threat models and contractual obligations, not from a preferred ORM pattern. If a customer requires residency or audit-proof separation, the architecture must say so explicitly.
Row-level security done right
Postgres RLS is powerful when tenant context is set on every connection and policies are tested as thoroughly as application code. It fails when a service role bypasses policies or a reporting job reads without tenant filters.
Defence in depth still matters: application filters, RLS, and automated tests that attempt cross-tenant reads in CI. One layer alone will eventually be bypassed.
When to silo a tenant
Silo when the revenue justifies the ops cost, when compliance demands it, or when a tenant's workload would starve others. Partial silos — dedicated search indexes or object storage prefixes — often deliver most of the benefit without full stack duplication.
Plan migration paths early. Promoting a shared tenant to a silo under deadline is far harder than designing the escape hatch on day one.
Operational guardrails
Quota noisy neighbours with per-tenant rate limits and storage caps. Emit tenant IDs on every log and trace so incidents do not become forensic puzzles.
Isolation without observability is theatre. The goal is blast-radius control you can prove during a security review.
David Kim
Cloud Architect
Cloud architect specialising in Kubernetes, multi-tenant SaaS, and secure blockchain systems.
