DEV

Your Postgres multi-tenancy model is one of the most consequential early decisions in a SaaS build — and one of the hardest to undo. This episode breaks down all three isolation approaches so you can choose the right one before it costs you a painful rewrite.

Show Notes

Multi-tenant data isolation isn't a detail you can defer — it's a foundational architectural choice that shapes migrations, compliance posture, backup strategy, and blast radius from day one. This episode of DEV.co walks through the three Postgres isolation models available to SaaS teams, drawing on this deep-dive on multi-tenant Postgres isolation for SaaS to help founders and engineers make an informed decision before it becomes an expensive one to reverse.

The episode covers all three viable approaches in honest, practical detail — including where each one breaks down at scale:

  • Shared schema (tenant ID column): The most common starting point — lowest per-tenant cost and simplest migrations, but widest blast radius; Postgres row-level security is essential, not optional, to close the data-leak gap.
  • Schema-per-tenant: Meaningfully stronger isolation and trivially simple per-tenant backups or GDPR deletions, but Postgres catalog overhead starts to buckle around 500 tenants, and migrations become a distributed systems problem that requires a purpose-built runner.
  • Database-per-tenant: The compliance answer for regulated industries and enterprise contracts with data-residency requirements — but every database is a separate migration target, backup schedule, and monitoring endpoint, making it operationally costly without a genuine contractual reason.
  • Hybrid routing layer: A pragmatic middle ground that uses shared schema for the long tail of smaller tenants while routing enterprise accounts to dedicated databases — with a tenant directory abstraction that's worth building carefully regardless of which model you start with.
  • Horizontal scaling with Citus: When a single Postgres primary is no longer enough, Citus preserves the standard Postgres interface while distributing data by tenant ID; the Notion architecture — workspace ID as the partition key, 480 logical shards across 32 physical databases — is the canonical reference point.
  • The four-input decision framework: Expected tenant count at 24 months, data sensitivity, whether any single customer will pay for dedicated isolation, and the team's operational maturity to run multiple databases.

For more on building thoughtfully with AI-assisted workflows in the same codebase where these decisions live, check out the DEV.co episode Why Vibe Coding Still Requires a Human Element.

DEV.co

RFP.co

What is DEV?

Software and web development from the side that has to ship it and then live with it. Architecture decisions with a cost attached, scoping, technical debt, hiring and vendor selection, and the AI tooling question every engineering team is now answering whether they planned to or not.

Each episode takes one decision — rewrite or refactor, framework choice, build versus buy, how to scope a fixed-bid project honestly — and works through the tradeoffs, including the ones that only show up in year two. Written for engineering leads, technical founders and the people who fund them. Five or six minutes, no hand-waving.

Topics include rewrite versus refactor, build versus buy, scoping fixed-bid work honestly, technical debt you should keep, framework and platform choices, hiring and vendor selection, code review culture, and where AI tooling actually helps.

Produced by DEV.co, web and software development. Full details, services and further reading at https://dev.co