Field noteBy The Relmz team
Thinking through multi-tenant Postgres at small scale
DB-per-tenant is operationally expensive — until you need it. Here's how we landed there, and what we'd say to anyone shipping multi-tenant SaaS in 2026.
There are three multi-tenant patterns worth comparing: shared schema with tenant_id columns, shared cluster with one schema per tenant, and one database per tenant. Most blog posts make this look like a reasoned choice. In practice, it's a stack of trade-offs you only feel after the fact.
We ended up with one database per tenant. The blast radius is the smallest. Backups are per-customer. Per-tenant Postgres extensions and configs become a knob, not a fight. Provisioning costs more — every tenant needs a migration run on first sign-in — but the cost is paid once.