Connection pooling breaks in a specific, sharp way. Bridge routing usually works by setting search_path per request. Under a transaction-pooling proxy (Module P-4), a server connection is handed to a different client after each transaction, so any session-level state you set outside a transaction can leak into another tenant's next query:

That works, and it costs you: every tenant-scoped read is now a transaction, prepared-statement caching is per-search_path so plan caches multiply, and you have surrendered the option of session-level pooling. The alternative — a pool per tenant — multiplies Postgres's default max_connections of 100 against a per-connection cost that is a forked backend process, and exhausts the server long before it exhausts your tenant list.

The judgement: choose bridge only if you have a firm ceiling on tenant count — a few hundred, contractually — and you actively want per-schema dumps. If the product's growth story involves self-service signup, bridge is a migration you will have to do later under pressure.

---

Pool's Failure Mode Is a Single Missing Predicate

In the pool model the tenant boundary is WHERE tenant_id = $1. That predicate is now a correctness requirement in every query, in every service, in every background job, in every ad-hoc script an engineer runs during an incident. One omission and the endpoint returns everyone's data — usually a list endpoint, usually added in a hurry, usually discovered by the customer.

Code review and integration tests reduce the rate. They do not change the shape of the risk, because they rely on remembering something. The same four failure modes Module F-13 gave for application-level validation apply verbatim: a second writer, a bulk job, an admin script, and a new code path that forgets.

Row-level security is the structural fix. It moves the predicate from every query into the table definition, where forgetting is no longer possible:

USING filters what is visible to reads, updates, and deletes; WITH CHECK stops a write from creating a row belonging to another tenant. Both are needed — a policy with only USING lets an insert plant a row you can then no longer see.

The tenant is supplied per request, and it must be transaction-scoped for exactly the pooling reason above:

What RLS costs, stated honestly:

• The policy is a predicate the planner must satisfy on every access. With the right indexes it collapses into the same index scan you'd have written by hand; with the wrong ones it turns a seek into a filter over the whole table. Which means: every index on a pooled table should lead with tenant_id — (tenant_id, created_at DESC), not (created_at DESC) — by Module F-13's leftmost-prefix rule. This is the single most common pool performance mistake.
• Superusers and roles with BYPASSRLS ignore policies. Your migration role probably needs to; your application role must not have it.
• Debugging gets less obvious. A query that returns nothing because app.tenant_id was never set looks like missing data, not like a security control working correctly. Fail loudly: make the setting's absence an error rather than a default.
• It is a defence in depth, not an authorisation system. RLS faithfully enforces whatever tenant id you hand it. Deciding that the caller is entitled to that id is Module A-13's problem.

A useful middle option inside pool: partition the largest tables by tenant_id (list partitioning for named large tenants, hash for the long tail). You keep one schema and one migration, and you regain some silo-like properties — partition-level maintenance, cheaper bulk deletion of a departing tenant, and partition pruning that keeps a whale's data out of everyone else's index pages. The cost is the usual partitioning cost from Module P-6: every query wants the partition key, and cross-tenant queries fan out across all partitions.

---

Noisy Neighbours Are the Real Subject

Isolation models are a one-time decision. Noisy neighbours are a permanent operating condition, and they are what actually pages you.

The mechanism is always the same: tenants share a finite resource, one tenant's demand spikes, and the resource is consumed by whoever asked first. Every shared resource in your stack is a candidate — connection-pool slots, database CPU and buffer cache, disk IOPS, WAL throughput, background-worker capacity, Redis memory and its single-threaded command loop, outbound API quota to a third party you both depend on. Note that this is Module F-13's one-slow-query cascade with a new twist: the query is legitimate, it belongs to a paying customer, and it is destroying your p99 for everyone else.

Tenant traffic is reliably power-law distributed. A small number of tenants generate most of the load, the largest tenant is often larger than the next ten combined, and the distribution shifts when one customer's own product goes viral. Any capacity plan built on average tenant size is wrong in the direction that hurts.

Four levers, in the order they usually pay off.

1. Per-tenant rate limits and quotas. The boundary is the natural limit key, so the limiter's counters are keyed by tenant rather than by IP or user. Two distinct things are needed: a rate limit (requests per second, to protect latency) and a quota (units per month, to protect cost and to make plan tiers mean something). The mechanics — token bucket versus sliding window, where the counters live, what happens when the limiter itself is down — are Module P-18. The design point here is that rate limits alone are insufficient, because request count is a poor proxy for cost: one cheap-to-issue report request can consume more database time than ten thousand key lookups. You also need to limit expensive work by its own units — concurrent exports per tenant, rows scanned, job slots held.

2. Dedicated capacity for whales. Once a tenant is large enough that its variance is visible in your aggregate metrics, stop pooling its compute. In escalating order of cost: a dedicated worker pool for its background jobs, then a dedicated application deployment, then its own shard or replica, then a full silo. Each step buys isolation and charges you a fleet-management increment plus a routing layer that must know which tenants are special. The routing table is the part to design deliberately — a tenants.shard_id column consulted at request entry, not hostname conventions scattered through config.

3. Tenant-aware connection budgets. This is the one most often missed, and it's the one that turns a single tenant's slow report into a full outage. If a pool of 20 connections per instance is first-come-first-served, one tenant with a burst of slow queries takes all 20 and every other tenant queues behind it (Module P-4). The fix is a bulkhead (Module A-7) at the tenant granularity: cap how many connections or in-flight queries any one tenant can hold, so the worst case for others is degradation rather than starvation.

The cost is real and should be named: a tenant that would have succeeded by waiting now gets an error, and the cap is per-instance rather than global unless you centralise the counter (which adds a network round trip to every query). Per-instance caps with a global limiter for the expensive paths is the usual compromise.

4. Per-tenant query timeouts. statement_timeout set per transaction, differentiated by tenant tier and by workload class — a few seconds for interactive requests, longer for a batch export running on a dedicated worker. This converts "one tenant holds a connection for five minutes" into "one tenant's request fails", which is a far better outage. It is close to free and routinely absent.

Why this matters in production: without per-tenant limits, your effective SLO is set by your least disciplined customer. With them, a tenant that misbehaves degrades itself first, which is both the correct blast radius and — because the limit produces a specific, attributable error — the fastest possible diagnosis. Module O-2's error budget is only defensible if a single tenant cannot spend it.

All four levers depend on measuring per tenant, which has its own cost: tagging metrics with tenant_id multiplies time-series cardinality by tenant count, and metrics systems price cardinality (Modules O-1, O-8). The workable pattern is full per-tenant detail for the top tenants by usage, aggregate buckets for the long tail, and per-tenant attribution in logs and traces where cardinality is cheaper than in metrics.

---

Promoting a Tenant Out of the Pool Without Downtime

Eventually one tenant outgrows the pool: it dominates your largest tables, its reports move the shared p99, or it buys a contract requiring its own database or its own region. You need to move one tenant's data out of shared tables and into a silo while it keeps writing.

The naive version is a maintenance window: stop writes, export the tenant's rows, import, flip routing. It works, it's honest, and for a small tenant on a weekend it may be the right answer — the cost is a scheduled outage for one customer, which is sometimes cheaper than the machinery below. For a large tenant, the export alone outlasts any window you'd be allowed.

Two approaches that avoid the window.

Dual-write. The application writes every change for that tenant to both the pool and the new silo during the transition. Backfill historical rows in batches behind the live writes, then verify, then cut reads over, then stop writing to the pool. This is simple to describe and it inherits the dual-write problem from Module F-14 in full: two writes without a shared transaction can partially fail, so the two copies diverge silently under exactly the conditions you can't reproduce — a crash between the writes, a timeout on the second one, out-of-order concurrent updates to the same row. If you take this path you need a reconciliation job comparing the two copies continuously, not once, and it should be able to repair as well as report.

CDC-based. Stream the tenant's changes out of the source database's replication log and apply them to the target. The write path stays single-destination, so there is no divergence window to reason about, and the log gives you ordering for free. The steps:

1. Create the target silo with the same schema. Start the change stream from a known log position before the snapshot you're about to take.
2. Copy the tenant's rows — WHERE tenant_id = X across each table — in batches sized to avoid long-running transactions (Module F-13: a long transaction blocks vacuum database-wide, and the pool is shared, so this batching protects other tenants).
3. Apply buffered changes from the stream position onward. The apply must be idempotent, because you will replay: upsert by primary key, and use the source's version or log position to reject out-of-order applies (Module P-16).
4. Wait for replication lag to reach steady state — seconds, not minutes.
5. Verify: row counts per table, and checksums over the rows. Reconcile the differences before you trust it.
6. Cut over reads. Then briefly fence writes for this tenant (reject with a retryable error for a few seconds, which clients retry through per Module A-6), confirm the stream has drained, and flip the routing entry.
7. Keep the pool's copy read-only for a rollback window, then delete it. Deleting the tenant's rows from the shared tables is itself a batched job that generates substantial bloat.

The mechanics of change streams — snapshot-then-stream, log retention, at-least-once delivery, and what happens when the consumer falls behind — are Module P-23. The cutover discipline, feature-flagged routing, and expand/contract sequencing are Module O-4. This is through-line 2 arriving at a tenant-shaped problem: CDC is how data leaves a database, whether the destination is a warehouse or another tenant's new home.

The cost of building this: a routing indirection on every request, a tenant-aware data-access layer that can talk to either topology, and two deployment shapes to test. Which is why the recommendation is to build the routing indirection on day one, while it is a single function returning a single connection, and defer everything else. Retrofitting tenant routing into a codebase that assumed one database is the expensive version of this work.

---

Where This Shows Up in Your Stack

• PostgreSQL: RLS with FORCE ROW LEVEL SECURITY and both USING and WITH CHECK; set_config(..., true) rather than SET so the tenant id dies at COMMIT; every index on a pooled table led by tenant_id; list/hash partitioning on tenant_id for the largest tables; per-transaction statement_timeout by tenant tier. If you are on bridge, watch pg_class row counts and catalogue bloat as first-class capacity metrics.
• Node.js: one withTenant() wrapper that every tenant-scoped query passes through — it sets the tenant, the timeout, and the concurrency cap in one place, and it is the only realistic way to make the boundary unforgettable. Never carry the tenant id in a module-level variable; use an AsyncLocalStorage context so a concurrent request can't read another's.
• Redis: key-prefix every tenant (t:{tenantId}:...) so eviction, scanning, and per-tenant flush are all possible; remember that Redis memory is a shared resource, so one tenant caching large objects evicts everyone else's hot keys (Module F-12's LRU flood, with a tenant attached). For a whale, a separate instance or a dedicated logical database.
• pgBouncer / connection proxies: transaction pooling is incompatible with session-level search_path or SET, which is the mechanism by which bridge and pooling collide. Decide which you need before you have both (Module P-4).
• Kafka: partition-key by tenant when ordering per tenant matters, and accept that one large tenant makes one partition hot — the consumer-group rebalance and the hot-partition remedy are Module P-15.

---

Summary

• Multi-tenancy is a partitioning and capacity problem first — where the tenant boundary sits in the storage layout, and how you stop one tenant eating a shared resource. Proving the caller owns the tenant is a separate problem (Module A-13).
• Silo isolates best and charges you a fleet — N migrations with partial-success semantics, and a per-tenant cost floor that makes small tenants unprofitable. It works well as a tier, rarely as the whole architecture.
• Bridge breaks tools rather than models — catalogue pressure from tens of thousands of relations, logical dumps that stop being practical, and a direct collision between per-request search_path and transaction-mode pooling. Choose it only with a hard ceiling on tenant count.
• Pool is the right default and its failure mode is one missing predicate — a query without tenant_id returns everyone's data, and code review only lowers the rate.
• Row-level security is the structural fix — FORCE ROW LEVEL SECURITY, both USING and WITH CHECK, tenant set transaction-scoped so pooling can't leak it. It costs planner work, so every pooled index must lead with tenant_id.
• Noisy neighbours are the permanent condition, not the one-time decision. Tenant load is power-law distributed; a plan built on the average tenant is wrong where it hurts.
• Four levers: per-tenant rate limits and quotas (Module P-18, because request count is a poor proxy for cost), dedicated workers or shards for whales, tenant-aware connection budgets that fail fast instead of queueing (Modules P-4, A-7), and per-tenant statement_timeout.
• Per-tenant measurement costs metric cardinality — full detail for top tenants, buckets for the tail, attribution in logs and traces (Modules O-1, O-8).
• Promote a tenant out of the pool with CDC, not dual-write — dual-write inherits Module F-14's divergence problem and needs continuous reconciliation; CDC gives ordering and a single write path (Modules P-23, O-4). Build the routing indirection on day one; defer the rest.

The next module, Specialty Datastores: Wide-Column, Graph, and Time-Series, takes the tenant boundary you've just chosen and asks what happens when the workload no longer fits a relational engine at all — wide-column stores that make tenant_id part of a mandatory partition key, and time-series engines where per-tenant retention and downsampling become the isolation mechanism.

---