Silo, pool, bridge: what each tenant gets to itself
Silo: dedicated resources, walled by infrastructure. Pool: shared, tenant ID on every request and row. Bridge: shared app, database per tenant.
Silo or pool?
Bad: One label for the system
Sounds like you haven’t found where the risk is.
Good: Per layer, per service
Pool the stateless web tier; silo the data tier regulators care about.
Each service picks for its compute and its data
Orders pool both. Documents get a bucket per tenant. Integrations run customer scripts in a sandbox each. Analytics silo both for heavy queries.
58×
cheaper per tenant in a pool of 2,000
Assume a $350 floor per silo. A pool spreads a $3,000 floor and adds $4.50 a tenant, $6 each. Below ≈9 tenants, silos win.
Cap the blast radius: many identical pools, not one
Each stamp holds up to 250 tenants behind a thin router. When stamp 2 fails, 250 of 920 tenants feel it, not all.
Acme upgrades to enterprise. Move it, online.
- Build its silo from the same template
- Copy its rows, then stream changes
- Freeze writes briefly and flip the route
- Verify, then delete the pool copy
Pools for most, silos for a few. Two codebases?
The clean design
A silo is a pool of one. Same code everywhere; the control plane just places that tenant on its own deployment.
Remember
Decide per layer and per service: pool the long tail in stamps, silo enterprise or regulated tenants, same code everywhere.