Multi-Tenant SaaS Data Architecture: Silo, Bridge, Pool (2026)

Q: When should I choose silo (database per tenant) vs pool (shared schema) for a SaaS platform?

Silo is right for a small number of large tenants — typically tens to low hundreds — where strong isolation, per-tenant compliance requirements (data residency, dedicated encryption keys, contractual data sovereignty), or per-tenant SLA commitments justify the higher per-tenant infrastructure cost. Pool is right for thousands of small to medium tenants where unit economics demand low per-tenant overhead and the shared-tenancy risks (noisy neighbour, cross-tenant leak via missing WHERE clause) can be managed with defence in depth (Postgres RLS, query analyzers, runtime guards). The bridge model (one schema per tenant in a shared database) is the middle ground for hundreds of tenants, offering meaningful isolation without silo cost. Most production platforms eventually run all three, sharded by tenant tier — free in pool, mid-market in bridge, enterprise in silo — with a tenant catalogue routing each request to the appropriate backend. The single most common mistake is picking one model and hard-coding the routing, which makes future migrations expensive.

Q: Why is Postgres Row-Level Security so important in pool-model multi-tenancy?

In a pool model where every multi-tenant table has a tenant_id column and every query must filter by tenant_id, RLS is the difference between "one missing WHERE clause is a complete breach across all tenants" and "one missing WHERE clause returns zero rows." Without RLS, a single junior-engineer mistake — SELECT * FROM accounts WHERE email = $1 instead of SELECT * FROM accounts WHERE tenant_id = $1 AND email = $2 — exposes every tenant's data. With RLS, Postgres applies a policy filter automatically based on a session variable (SET LOCAL app.tenant_id = ...) that the application sets at the start of every transaction. The CREATE POLICY statement enforces tenant_id = current_setting('app.tenant_id') on every read and write. The overhead is typically 2-8% query latency, which is a trivial price for the safety guarantee. RLS is not a substitute for correct application code (still write filters in queries); it is the safety net that catches the inevitable mistake. Pair with a CI query analyzer that blocks PRs containing queries without tenant_id filters for defence in depth.

Q: How do I handle GDPR right-to-erasure in a multi-tenant SaaS architecture?

In silo, erasure is trivial: drop the tenant's database, drop their backups (or wait the retention window), drop their KMS key, drop their entry in the tenant catalogue. Hours of work, provably complete. In bridge, similar: drop the tenant's schema. In pool, erasure is genuinely hard: identify every multi-tenant table (typically 50-200 in a mature platform), generate DELETE statements with the tenant_id filter, execute in batches with rate control, then propagate the erasure to read replicas, analytics warehouses (often a separate ETL cycle), search indexes, log archives, exported PDFs in object storage, third-party services (email, payments, support tools), and the cache layer. The full pool-model erasure typically takes weeks across all systems and requires a written data-flow inventory documenting every place tenant data flows to. Crypto-shredding offers a fast-path: deleting the tenant's per-tenant DEK makes data unreadable within minutes even though physical deletion runs over weeks. Build the data-flow inventory from day one — the first GDPR request always finds undocumented data flows that cause delays.

Q: How does envelope encryption with per-tenant keys actually work?

Each tenant has a customer master key (CMK) stored in a KMS (AWS KMS, GCP KMS, Azure Key Vault, HashiCorp Vault). Per-record data is not encrypted with the CMK directly — that would mean a KMS call on every read, which is slow and expensive. Instead, generate a fresh data encryption key (DEK) per record (or per batch), encrypt the data locally with the DEK, then call KMS once to "wrap" the DEK with the tenant's CMK and store the wrapped DEK alongside the encrypted data. To decrypt: read the wrapped DEK, call KMS to unwrap it using the tenant's CMK, then decrypt the data locally. Cache decrypted DEKs in application memory with short TTLs (5-15 minutes) so the KMS call rate is decoupled from the data access rate. The tenant's CMK never leaves the KMS. Key rotation re-wraps existing DEKs with the new CMK without re-encrypting data — fast even at scale. Crypto-shredding for erasure: delete the CMK and all data encrypted with it becomes structurally unreadable. Per-tenant key revocation (suspend account, restore later) is reversible at the KMS layer without touching any rows.

Q: How do I build a tenant catalogue and why does it matter so much?

The tenant catalogue is a small data store (typically Postgres, sometimes DynamoDB or a service registry) keyed by tenant_id, returning the tenant's tier, backend assignment (silo DB connection string, bridge schema name, pool shard ID), KMS key reference, region, feature flags, and any per-tenant configuration. The application reads it at every request via the connection router; results are cached in-process for 30-300 seconds (lower during active migrations). The catalogue matters enormously because it is the indirection layer that makes future migrations possible without application changes. Without it, the connection between tenant_id and database backend is hard-coded, and migrating a tenant from pool to silo (or splitting a shard, or moving to a new region for residency compliance) requires application code changes per tenant. With it, the migration is a catalogue update plus a one-time data copy. Build the catalogue on day one even if every tenant currently routes to the same pool backend — the indirection costs nothing and pays back enormously when the first migration is needed.

Q: What is the noisy-neighbour problem in multi-tenant SaaS and how do I mitigate it?

In a pool model, all tenants share database CPU, IO, connection pool slots, buffer cache, and lock contention. One tenant running a heavy query — a full table scan on a 200 GB table, a long-running transaction holding locks, a sudden burst of writes — degrades latency for every other tenant on the same database. Mitigation strategies. (1) Per-tenant query attribution via pg_stat_statements with tenant tagging — identify the noisy tenant in seconds rather than after a long incident investigation. (2) Per-tenant rate limiting at the application layer (covered in distributed rate limiting article) using tenant_id as the natural key, with stricter limits on tier classes that should not run heavy workloads. (3) Read replicas dedicated to long-running analytical queries, isolated from the OLTP workload. (4) Migrate the heaviest tenants to bridge (their schema isolated from others within shared cluster) or silo (their own database, fully isolated). The hybrid model where free/SMB tenants are pooled, mid-market are bridged, and the noisiest tenants are silo'd is how mature platforms balance unit economics against noisy-neighbour blast radius. Without per-tenant attribution, you cannot identify the noisy tenants — build attribution from day one.

Q: How do I migrate a single tenant from pool to silo without downtime?

A multi-week project the first time, a multi-day project after the tooling is built. Phase 1: provision a new database for the tenant (silo backend) and apply the platform schema. Phase 2: bulk-copy the tenant's data — query every multi-tenant table for rows where tenant_id = T, insert into the new database (without the tenant_id columns since silo doesn't need them). For large tenants, use parallel copy with logical replication or a CDC tool. Phase 3: enable dual-write — every application write for tenant T goes to both pool and silo, with comparison logging to catch divergence. Phase 4: enable dual-read with shadow-mode comparison — every read serves from pool but compares the silo result, alerting on any differences. Phase 5: cutover by updating the tenant catalogue to route tenant T to silo; a brief connection-pool drain absorbs in-flight requests. Phase 6: drop the tenant's data from pool tables (with foreign-key consideration). Validation throughout: row counts per table, checksum comparisons, business-logic invariants. Never migrate via a single-shot copy-and-cutover for any tenant whose data matters — always dual-write/dual-read with extensive validation. The first migration teaches the team what tooling needs to exist; subsequent migrations are straightforward.

Q: How do I do per-tenant cost attribution in a pool deployment?

Cost attribution in pool requires explicit instrumentation because the underlying infrastructure does not segment per tenant. Tag every database query with its tenant_id (most ORMs allow query annotations or comment-injection that survive into pg_stat_statements). Aggregate query duration and rows-affected per tenant in a metrics pipeline running daily. Tag every cache lookup with tenant_id and aggregate cache hit/miss/byte counts per tenant. Tag every external API call (email, SMS, payment gateway, AI/LLM provider) with tenant_id and aggregate call counts and unit costs per tenant. For object storage and CDN bandwidth, tag at the upload/download layer. Combine all sources in a monthly cost-attribution job that produces per-tenant infrastructure cost in dollars. The first time the report runs, expect surprises: in any pool deployment with thousands of tenants, the top 1% typically consume 30-60% of platform resources; some tenants will be costing more than they pay in subscription. With this data, corrective actions become possible: tier-specific pricing, usage caps, migration to higher tier, or migration to bridge/silo where the cost is naturally attributable. Without the data, pricing decisions are guesses and the unit economics of the business are opaque.

Q: When does the bridge (schema per tenant) model make sense over pool or silo?

Bridge is the right choice in three scenarios. (1) Hundreds of mid-market tenants where some isolation is needed (regulatory, contractual, or noisy-neighbour mitigation) but per-tenant database overhead would be uneconomic. The shared cluster has one engine, one connection pool, one set of monitoring, but each tenant's schema is isolated from the others. (2) Tenants who need their own backups and restores but not their own database engine — Postgres pg_dump --schema=tenant_xxx works; restore is straightforward. (3) Tenants who want simpler "their data is in their own schema" assurances without the cost of silo. Trade-offs to plan for: schema migrations now must execute against N schemas (manageable up to a few hundred, painful at thousands; build parallel-execution tooling early); Postgres has practical limits on the number of schemas before catalog operations slow down (test in advance for your tenant count); cross-schema queries are awkward; backup at the schema level requires custom scripting or per-schema dumps. Bridge is underrated in production architectures because most teams know pool and silo but skip the middle. For the right tenant count and tier mix, bridge is the most cost-effective isolation choice.

Q: What infrastructure should I build on day one for a future-proof multi-tenant SaaS?

Six pieces of infrastructure that look unnecessary at day one and turn out to be the most valuable engineering investment by year three. (1) Tenant catalogue: a data store keyed by tenant_id returning backend assignment, KMS key reference, tier, region. The indirection that makes future migrations possible. (2) Connection router: a small library that reads the catalogue and returns the right database connection per request, sets RLS session variables, sets schema search paths. Keep on the application hot path with no extra network hop. (3) Postgres RLS on every multi-tenant table, with the SET LOCAL app.tenant_id call wired into the query path. The safety net that catches missing-WHERE-clause bugs. (4) Per-tenant cost attribution: tag every query, cache lookup, external API call with tenant_id; aggregate monthly. The data needed for pricing decisions. (5) Per-tenant KMS keys (envelope encryption) even if every tenant currently uses the same logical CMK class — the indirection is what enables crypto-shredding, key revocation, per-tenant rotation. (6) Data-flow inventory: a written document listing every place tenant data flows to (databases, replicas, analytics warehouse, search, caches, object storage, third-party services, log archives) with retention policy and erasure verification owner. The artefact that makes GDPR right-to-erasure provably complete. Build all six on day one even if the platform has 10 tenants and the report consumers do not exist yet — the cost of building them later, after the platform is large, is an order of magnitude higher.