Every early-stage SaaS team asks this question once, usually right before their first enterprise prospect asks about data isolation.
Shared schema with a tenant_id column
Cheapest to run, simplest to migrate, and the default choice for most early-stage products. The risk is entirely in query discipline — every single query needs a tenant_id filter, and a missed filter is a cross-tenant data leak. Row-level security at the database layer, not just application-layer filtering, is worth enabling from day one.
Schema-per-tenant
Better isolation, easier per-tenant backup/restore, but migrations now run N times instead of once. This becomes painful past roughly 50-100 tenants unless your migration tooling is genuinely automated.
Database-per-tenant
Strongest isolation, and sometimes a compliance requirement (some healthcare and financial contracts mandate it explicitly). Highest operational overhead — connection pooling, monitoring and cost all multiply per tenant.
What we default to
Shared schema with enforced row-level security until a specific contract or compliance requirement demands otherwise. Migrating from shared schema to schema-per-tenant later is a known, bounded project; starting with database-per-tenant for a 5-customer product is not.
Our SaaS Product Development team can help you make this call for your specific compliance and scale requirements.