Blog Details

Every multi-tenant SaaS product eventually has to answer the same question: how strictly should one customer's data be separated from another's? On PostgreSQL, that decision usually comes down to two patterns — a shared schema with a tenant_id column on every table, or a dedicated schema per tenant inside the same database. We've built products on both ends of that spectrum, and the right answer has consistently depended on the domain, not on which pattern is fashionable.

Shared Schema: Simple Until It Isn't

A shared schema — one set of tables, every row tagged with a tenant identifier — is the fastest way to ship. Migrations run once, connection pooling is trivial, and cross-tenant analytics are a single query away. This is the model behind QTable's restaurant tenants and POWER RESEARCH's branch-level isolation: the tenant count is large but each tenant's data footprint is modest, and the operational simplicity of one schema outweighs the isolation benefits of separating them.

The catch is discipline. Every query, every background job, every report needs a tenant filter, and a single missing WHERE tenant_id = ... is a data leak waiting to happen. Row-level security helps, but it has to be treated as a hard requirement from day one, not retrofitted later.

Schema-per-Tenant: Isolation as a Feature

For TradeCheck, we went the other way. Each tenant — a bank, a trading company — gets its own PostgreSQL schema, addressed through a schema_translate_map and a subdomain per organization. That buys real isolation: a bad migration or a bug in one tenant's data can't silently corrupt another's, backups can be scoped per tenant, and "delete everything for this customer" is an operation on one schema instead of a filtered delete across dozens of tables. It costs more in migration tooling — every schema needs the same DDL applied — and in connection management, but for a product handling financial documents, that trade-off is the right one.

How We Decide

In practice, the decision comes down to three questions: how sensitive is the data if it leaks across tenants, how many tenants will there realistically be, and how much does per-tenant customization matter? High sensitivity and lower tenant counts push toward schema-per-tenant; high tenant counts with fairly uniform, lower-risk data push toward a shared schema with strict row-level filtering. Neither pattern is "more advanced" than the other — they solve different problems, and picking the wrong one for your domain is a much bigger risk than picking either one badly implemented.