The Three Multi-Tenancy Models

Model 1: Shared Database, Shared Schema

All tenants share the same database tables. Each row has a tenant_id column that scopes it to its owner. This is the simplest model to implement and the most common starting point.

Pros: Simple to build, easy to maintain, cheap to operate — one database handles all customers.

Cons: A missing WHERE tenant_id = ? clause anywhere in your codebase exposes one tenant's data to another. The risk of data leakage is real and grows with codebase complexity.

When to use: Early-stage SaaS, where customers don't have strict data isolation requirements and you can enforce tenant_id filtering at the ORM or query layer.

Model 2: Shared Database, Separate Schemas

One database, but each tenant gets their own schema (PostgreSQL terminology) or namespace. All tables are duplicated per tenant, but no cross-tenant data sharing is possible at the database level.

Pros: Strong isolation without the cost of separate databases. A bug in the query layer can't leak data between tenants.

Cons: Schema migrations must run for every tenant simultaneously. As you scale to thousands of tenants, migration management becomes complex.

When to use: When you need stronger isolation guarantees without the infrastructure overhead of per-tenant databases.

Model 3: Separate Database Per Tenant

Each customer gets their own database instance. Maximum isolation, maximum complexity, maximum cost.

Pros: True data isolation. Enterprise customers with strict compliance requirements (finance, healthcare, government) often require this. Easy to give customers their own backups, exports, and SLAs.

Cons: Expensive to operate at scale. Migrations must be coordinated across potentially thousands of database instances. On-call incidents affect more surfaces.

When to use: When regulatory compliance demands it, or when you're serving large enterprise customers who contractually require data separation.

Implementation Decisions That Matter Early

Choose your isolation model at day one. Migrating from shared-schema to separate-schema after you have hundreds of customers means rewriting data access patterns across your entire codebase. Decide upfront, even if you're starting simple.

Enforce tenant isolation at the data layer, not just the application layer. Row-level security (RLS) in PostgreSQL lets you define policies that automatically filter queries by tenant. This is more reliable than relying on application-level WHERE clauses — a forgotten clause in application code can't bypass a database-level policy.

Design your URL structure for tenants from the start. Will tenants access your app at app.yourproduct.com/tenantname, tenantname.yourproduct.com, or a fully custom domain? Custom subdomains or domains require more infrastructure but signal professionalism to enterprise customers. Changing your URL structure after launch is painful.

Plan for tenant onboarding automation. Manually provisioning each new customer doesn't scale past ~20 customers. Build self-serve tenant provisioning from the beginning — it's cheaper to automate now than to build it under pressure when sales are closing deals faster than your ops team can provision.

The Multi-Tenant Security Checklist

Before your first paying B2B customer, verify:

• Every database query that returns user data is scoped by tenant_id
• API endpoints verify that the requesting user belongs to the tenant they're querying
• Admin tools that bypass tenant scoping require explicit permission checks
• Logging systems don't mix tenant data in shared log streams without scoping
• Tenant data can be exported and deleted independently (for GDPR compliance)

Multi-tenancy architecture isn't glamorous, but it's the foundation that lets a two-person engineering team serve thousands of customers without proportional infrastructure cost. Build it correctly once, and it becomes invisible. Ignore it, and it will cost you a major security incident or an architectural rewrite at exactly the wrong moment.