The hard part of SaaS architecture isn't getting to 100 customers. It's getting to 100 customers without painting yourself into a corner you'll spend a year escaping.
Here's the pattern we deploy for new B2B SaaS builds in 2026 — opinionated, GCP-native, designed to survive growth from 0 to 10,000 tenants without a rewrite.
Tenancy model: shared schema, tenant ID column
For new SaaS in the B2B mid-market, shared-schema-with-tenant-ID wins almost every time:
- One Postgres database (Cloud SQL or AlloyDB), every row carries a
tenant_id. - Row-level security enforces tenant isolation at the database layer, not just in app code.
- Schema-per-tenant and database-per-tenant patterns exist, but they create operational pain (migrations across thousands of schemas) that isn't worth paying for the marginal "isolation" benefit.
Enterprise customers occasionally need dedicated infrastructure. Handle that as a separate offering with its own deployment pipeline — don't let it pollute the main architecture.
Compute: Cloud Run, one service per bounded context
- One Cloud Run service per major bounded context (auth, billing, core app, etc.).
- Internal services talk over private VPC, public API surface through a single Cloud Load Balancer.
- Don't start with microservices. Start with three services. Split when the boundaries hurt.
Data: be deliberate about what's in Postgres and what isn't
- Transactional data: Postgres.
- Analytical / reporting: BigQuery, fed by a daily export job.
- Object storage: Cloud Storage with signed URLs.
- Caching: Memorystore (Redis) for session and hot lookups.
The mistake we see most is treating Postgres as the universal store — then watching it struggle when an analytics query runs against production tables.
Identity: Identity Platform from day one
Don't roll your own auth. Identity Platform (Firebase Auth's enterprise sibling) handles SSO, MFA, social logins, and OIDC providers for $0.0055/MAU. It's been the right answer for three years and is still the right answer.
Observability before launch
- Cloud Logging with structured logs everywhere
- Cloud Trace on all inter-service calls
- An uptime check on every customer-facing endpoint
- A budget alert at 50%, 80%, and 100% of monthly spend
If you can't tell what's slow without SSHing into a box, you're already behind.
What survives at scale
The pattern above has carried clients from 10 to 5,000 tenants without an architectural rewrite. The places it eventually breaks are predictable (database sharding, async heavy workflows) and addressable incrementally — not "stop everything for six months."
The architectural decision worth obsessing over isn't the database engine or the deployment platform. It's whether the choices you make today force you to rewrite when you 10x.
If they don't, you're free to actually build the product.
