Can we migrate from Pool to Silo later?

Yes, but it's meaningful engineering work — typically 1-3 quarters depending on data volume and downtime tolerance. Design tenant_id boundaries cleanly from day one so migration is possible when enterprise demand arrives.

Is single-tenant more secure?

By blast radius, yes — a bug or breach affects one customer, not all. By security surface area, not necessarily — silo instances still run the same code and may lag on patches. Isolation and security are related but distinct.

Should we use different databases per tenant?

For SMB SaaS: no, one database with RLS and tenant_id columns is standard. For enterprise/regulated: sometimes yes, offered as a paid Silo option. Rarely: separate database technologies per tenant — that's usually a sign of accidental complexity, not architecture.

Multi-Tenant vs Single-Tenant: Isolation Models for SaaS

Multi-tenancy is how one codebase serves many customers safely.

Multi-Tenant Architecture: The Choice That Shapes Every Future Product Decision

Multi-tenancy is the architectural pattern where a single application instance serves many customer organizations ('tenants') from shared infrastructure. It's the foundation of the SaaS economic model — infrastructure amortized across all customers, releases shipped to everyone at once, unit costs that fall as scale grows. The specific isolation model you choose (how strongly one tenant's data is separated from another's) affects security, compliance, cost, and engineering complexity for the life of the product.

Three isolation models

(1) Pool (shared) — one database, one schema, tenant_id column on every table. Cheapest, fastest to build, biggest blast radius from bugs. Standard for SMB SaaS. (2) Silo (isolated) — one database per tenant. Strongest isolation, highest ops cost, standard for enterprise/regulated. (3) Bridge (schema-per-tenant) — middle ground: one database, one schema per tenant. Better isolation than pool, less ops overhead than silo. Most SaaS companies start Pool and migrate high-value tenants to Silo as enterprise deals require it.

Row-level security

In the Pool model, tenant isolation depends entirely on every query filtering by tenant_id. A single missed WHERE clause becomes a cross-tenant data leak — the single scariest bug in SaaS. Modern databases (Postgres RLS, Supabase policies) let you enforce isolation at the database level: policies that automatically filter every query by the connecting user's tenant_id. This turns 'developer must remember' into 'database enforces' — a dramatic security improvement.

The noisy neighbor problem

In Pool architectures, one tenant's heavy usage can degrade performance for all tenants. Mitigations: (a) rate limits per tenant on expensive operations, (b) queue prioritization by tenant tier, (c) read replicas for large tenants, (d) migrate the noisy tenant to Silo. Not addressing noisy neighbor eventually produces enterprise customer complaints ('the app was slow yesterday') that trace back to a different customer's batch job.

When to offer single-tenant

Single-tenant (Silo) instances are typically offered as an Enterprise SKU add-on ($20K-$100K+ premium annually). They make sense when: (a) regulatory requirements (some healthcare, financial services, government), (b) data residency requirements the multi-tenant deployment can't meet, (c) strategic accounts where blast-radius risk is unacceptable to the customer. Offering single-tenant to every enterprise buyer erodes SaaS economics; offering it selectively unlocks deals that wouldn't close otherwise.

Deployment models beyond SaaS

Some enterprise customers demand more than single-tenant SaaS — they want deployment in their own cloud (BYOC, Bring Your Own Cloud) or on-prem. BYOC (Confluent, Databricks) runs your control plane in your cloud and the data plane in the customer's VPC. On-prem is the extreme case — vendor-managed software running entirely on customer infrastructure. Each deployment model doubles the engineering complexity but unlocks a distinct enterprise segment.

Frequently asked questions

Can we migrate from Pool to Silo later?: Yes, but it's meaningful engineering work — typically 1-3 quarters depending on data volume and downtime tolerance. Design tenant_id boundaries cleanly from day one so migration is possible when enterprise demand arrives.
Is single-tenant more secure?: By blast radius, yes — a bug or breach affects one customer, not all. By security surface area, not necessarily — silo instances still run the same code and may lag on patches. Isolation and security are related but distinct.
Should we use different databases per tenant?: For SMB SaaS: no, one database with RLS and tenant_id columns is standard. For enterprise/regulated: sometimes yes, offered as a paid Silo option. Rarely: separate database technologies per tenant — that's usually a sign of accidental complexity, not architecture.