Silo, Pool and Bridge Models

Three ways to place tenants

Tenancy models describe how much infrastructure tenants share. In the silo model each tenant gets dedicated resources: its own database, sometimes its own compute or even its own cloud account. Isolation is strong and per-tenant cost is easy to see, but every tenant adds infrastructure to deploy, patch and monitor. In the pool model all tenants share the same application instances and the same database, separated only by a tenant_id and code-level or database-level rules. It is the cheapest and simplest to operate, but isolation depends on getting every query right, and noisy neighbours are a constant concern. The bridge (or hybrid) model mixes the two layer by layer: for example, shared stateless services in front of a database per tenant, or a shared database with a separate schema per tenant. Real products are rarely pure; they choose per layer.

From most shared to most isolated

Picture a slider. On the left, pool: everything shared. In the middle, bridge: some layers shared, some dedicated. On the right, silo: everything dedicated per tenant.

Hostel, PG and independent flat

Pool is a hostel dorm: cheapest, everyone shares rooms and the mess. Bridge is a PG with private rooms but a shared kitchen. Silo is renting your own flat: full privacy and control, but you pay for and maintain everything yourself.

Isolation is per layer

In interviews, avoid saying a product "is silo" or "is pool" as a whole. Say which layer: "compute is pooled, the database is per tenant, the cache is shared with tenant-prefixed keys." That precision shows you understand where isolation actually comes from.

Quick check: A product runs shared API servers, but every customer has a dedicated PostgreSQL database. Which model is this?

• Pure pool
• Pure silo
• Bridge (hybrid)
• Single-tenant on-premises