SaaS Architecture Decisions
That Haunt You at Scale

The Tenant Isolation Problem

The most consequential SaaS architecture decision is your tenancy model, and it is almost always made too quickly. Shared-database isolation is cost-efficient and operationally simple, but it makes certain enterprise requirements data residency, GDPR deletion, per-tenant performance guarantees dramatically harder to satisfy later.

Schema-per-tenant solves most of those problems at moderate cost. Database-per-tenant gives you the strongest isolation guarantee and is the right choice for regulated industries, but the operational complexity is significant. The decision you make on day one shapes every enterprise deal you can close two years later.

Most SaaS products do not fail because of bad features. They fail because an architecture decision made in week two becomes impossible to change when the product gains traction.

Auth System Mistakes

Most SaaS products bolt on SSO when their first enterprise prospect asks for it, and then spend three months engineering around an auth system that was never designed for SAML. The retrofit is painful because session management, permissions, and user identity are baked into the application at dozens of call sites.

The fix is simple in principle: use an identity provider Auth0, Clerk, or Okta from day one, even on the free tier. Design your user and tenant models to support multiple auth methods from the start. Adding SAML, SCIM, or MFA to a properly abstracted auth layer takes days, not months.

Billing Architecture

Usage-based pricing is where most billing architectures fall apart. Flat-rate subscriptions are straightforward. Usage metering requires an event collection layer, an aggregation pipeline, and a billing engine that can translate raw events into line items on an invoice all of which need to be accurate, auditable, and reliable.

Build the metering infrastructure before you launch usage-based pricing, not after your first high-volume customer gets an invoice that does not match their expectations. Stripe Billing and Orb both provide solid foundations, but the event pipeline feeding them is always your engineering responsibility.

Zero-Downtime Migrations

Schema migrations that require downtime are a SaaS anti-pattern. Maintenance windows are incompatible with global customer bases and enterprise SLAs. Yet most early-stage SaaS products run migrations that lock tables, because nobody planned for online schema changes from the start.

Use expand-contract (parallel-change) migrations: add the new structure alongside the old one, update application code to write to both, backfill, then remove the old structure. For structural rewrites, pg_repack and pt-online-schema-change handle most cases without locks. This discipline needs to be established before you have 100,000 rows in a table, not after.

Observability Gaps

When something goes wrong at 2am for your largest customer, you need to know which tenant is affected, what queries are running, and exactly when the degradation started within seconds, not minutes. Most scaling SaaS products discover they cannot answer those questions precisely when they need to most.

Instrument your application for per-tenant metrics from day one: request latency, error rates, and database query time broken down by tenant ID. Add structured logging with correlation IDs. Wire distributed tracing through every service boundary. The cost of doing this early is trivial compared to the cost of doing it under production incident pressure.