Building a Multi-Tenant SaaS Platform on GCP – Architecture Blueprint

Silo gives each tenant a fully dedicated stack — its own Cloud SQL instance, its own GKE namespace or Cloud Run service, sometimes its own GCP project. It's the strongest isolation (a bug or a runaway query in tenant A's stack cannot touch tenant B's) and the most expensive per tenant, since idle capacity for a low-traffic tenant is still fully provisioned. Pool puts every tenant on shared infrastructure — one Cloud SQL instance, one Cloud Run service, tenant data distinguished only by a tenant_id column or a request header — which is cheap and scales well for many small tenants, at the cost of one tenant's load or bug being able to affect others sharing the same physical resources.

Bridge is the pragmatic middle: pool the compute layer (one Cloud Run service handles every tenant's requests) but silo the data layer for tenants that need it (an enterprise tenant gets a dedicated Cloud SQL instance, reached through the same API and the same tenant-resolution logic as pooled tenants). This is the model most SaaS platforms converge on in practice — free and pro tiers pooled for cost efficiency, enterprise tenants siloed at the data layer for the isolation and compliance guarantees that tier's contracts require, without maintaining two entirely separate codebases.

Every request must resolve to exactly one tenant before it touches any tenant data, and that resolution has to happen at a layer the application trusts — not by reading a client-supplied tenant id out of a request body, which any client can forge to request another tenant's data. The reliable pattern: resolve the tenant from the authenticated identity (a JWT claim set at login, verified by signature, not a header the client can set arbitrarily), look up that tenant's isolation tier and target Cloud SQL instance/connection string in a small tenant-directory service or cached table, and only then execute the request against the correct data store.

For pooled tenants, this resolution ends in a tenant_id value used in every query's WHERE clause (or better, enforced via Postgres row-level security so a forgotten filter fails closed instead of silently returning all tenants' rows). For siloed enterprise tenants, resolution ends in a different Cloud SQL connection string entirely — the application code path is identical, only the connection pool it draws from differs, which is what makes bridge isolation maintainable as one codebase instead of two.

Within the pooled tier, there's a further choice: shared tables with a tenant_id column (simplest, cheapest, scales to many small tenants on one instance), or one schema per tenant within the same Cloud SQL instance (stronger logical isolation — a schema-level permission mistake affects one tenant's schema, not a shared table — at the cost of schema-count overhead and migration tooling that must apply changes across every tenant's schema). Most pooled SaaS tenants are well served by shared tables plus row-level security; schema-per-tenant earns its complexity when tenants need to bring their own read replicas or export tooling that's naturally schema-scoped.

Whichever choice, cross-tenant queries (an internal admin dashboard showing aggregate usage across all tenants) need their own explicit, audited code path that deliberately bypasses the per-tenant filter — never build that path by reusing the same query functions tenant-facing code uses with the filter accidentally omitted, since that's the exact bug shape that causes real data leaks.

The realistic failure: a free-tier tenant runs a heavy, unindexed reporting query (a full-table aggregate across a year of data) against the shared Cloud SQL instance pro-tier tenants also depend on. Cloud SQL's CPU and I/O are shared across every connection to that instance, so the free tenant's one slow query consumes disk I/O and lock time that pro-tier tenants' ordinary, fast queries now have to wait behind — pro-tier customers see elevated latency with no code change on their side, and the root cause is invisible unless you're looking at per-tenant query cost, not just aggregate instance metrics.

The recovery has two layers. Immediately: a connection-pool-level statement timeout kills the runaway query before it monopolizes resources indefinitely (statement_timeout in Postgres), and per-tenant rate limiting on expensive endpoints (see rate limiting algorithms) prevents one tenant from issuing that query repeatedly. Structurally: this is the signal that a tenant has outgrown the pooled tier — move it to a dedicated read replica or a siloed instance rather than tuning the shared instance indefinitely around one tenant's workload shape.