One database, one schema per customer, or one database per customer?

The question

We are a 4-person team building a B2B SaaS product (customers are mid-size companies, 200 to 2,000 tenants expected in the first two years, a few of them regulated and likely to ask about data isolation). We use Postgres. Should we isolate tenants with a shared schema and a tenant_id column enforced by row-level security, a separate schema per tenant, or a separate database per tenant? We want to pick once and avoid a painful migration later.

What each model said

Each answer is the model’s own words, with formatting marks removed.

• Claude Sonnet 5.5

  Shared schema with tenant_id plus RLS. At 200–2,000 tenants and four engineers, schema-per-tenant means thousands of schemas, which makes migrations slow, bloats the catalog, and complicates pooling, while DB-per-tenant is operationally prohibitive. Make tenant_id a required column everywhere from day one, enforce RLS with a non-superuser app role, and put tenant_id in the leading position of composite indexes. For the few regulated customers, offer a dedicated database later via the same codebase. Key assumption: tenants are small-to-mid and no contract demands physical isolation upfront.

• GPT-4.1

  Use a shared schema with tenant_id plus row-level security. This scales best for 200–2,000 tenants, minimizes operational complexity, and is well-supported in Postgres. It's production-proven and efficient for SaaS. Only use separate schemas or databases if tenants need full customizability or hard isolation for strict compliance, but that adds complexity and management overhead. If “regulated” just means strong logical isolation, this model suffices and is futureproof for most B2B SaaS.

• Gemini 3.5 Flash-Lite

  Use separate schemas per tenant. Key reasoning: Mid-size B2B SaaS customers and regulated buyers frequently demand hard data boundaries. Shared schemas with Row-Level Security invite catastrophic human error and bypass compliance audits. Conversely, separate databases per tenant create massive connection-pooling bottlenecks and management overhead in Postgres at 2,000 tenants. Schemas provide the ideal balance: strict logical isolation and easy compliance tooling without connection explosion. Assumption: Your total tenant count stays under 2,000.

• Grok 4.20

  Shared schema with tenant_id + RLS. Small team + 200-2k tenants makes per-schema or per-DB ops (migrations, monitoring, connection routing, backups) too expensive. One DB keeps everything simple, fast to iterate, and easy for analytics. Postgres RLS is mature and auditor-accepted when policies are tight and tested. Regulated customers are few; strong controls + transparency will satisfy them. Assumption: you won't face strict "separate DB only" mandates.