Definition

Multi-Tenant SaaS

Multi-tenant SaaS is the architecture where a single instance of a software service hosts many customer organizations (tenants) with strict logical isolation. It is the dominant pattern for cloud business software and the model Factory Labs uses, with schema-per-tenant Postgres isolation.

Last updated

Definition

Multi-tenant SaaS is the cloud software architecture where a single instance of a service hosts many customer organizations ("tenants") concurrently, with logical isolation preventing one tenant from seeing another's data. The contrast is single-tenant, where each customer gets a dedicated software instance and infrastructure.

Multi-tenancy is the dominant pattern for cloud business software because the economics work: a single team operates one application that serves thousands of customers, instead of operating thousands of applications that each serve one.

The isolation models

Multi-tenant deployments differ in how strict the isolation is at the data layer. The common patterns:

  • Row-level (single shared database, single shared schema). Every table has a tenant_id column. Application code filters every query by tenant. Risk: a missing WHERE clause leaks across tenants. Operationally simple, hardest to audit.
  • Schema-per-tenant (single shared database, schema per tenant). Each tenant gets its own Postgres schema (tenant_42). Application code uses SET search_path per request. Stronger isolation; if the search path is wrong the query errors instead of leaking. This is the Factory Labs model.
  • Database-per-tenant. Each tenant gets its own Postgres database. Strongest isolation, hardest to operate at scale (thousands of separate databases).
  • Instance-per-tenant (effectively single-tenant on shared cloud). Each tenant gets its own application + database stack. Highest isolation, highest cost, lowest density.

Schema-per-tenant is a sweet spot for B2B SaaS where customer-data sensitivity is high but per-tenant volumes do not justify dedicated databases.

What multi-tenancy has to handle correctly

A well-built multi-tenant SaaS gets the following right:

  • Tenant scoping on every read and write. No exceptions, no admin-bypass shortcuts. Tested at the framework level.
  • Encryption keys per tenant. A cross-tenant data leak should be cryptographically blocked, not just application-blocked.
  • Audit logs per tenant. Every access to a tenant's data is logged with the actor.
  • Backup and restore per tenant. Restoring one tenant should not require restoring all tenants.
  • Performance isolation. One tenant's heavy workload should not degrade another tenant's performance. Per-tenant rate limiting, query timeouts, resource caps.
  • Tenant lifecycle. Create, suspend, delete. The delete operation should be irreversible and complete (no orphan records in cross-tenant tables).

Missing any of these is how multi-tenant SaaS leaks data in the wild.

How Factory Labs implements multi-tenancy

Factory Labs uses:

  • Schema-per-tenant on Neon Postgres. Each tenant gets a dedicated Postgres schema. Every request sets the search path before any query.
  • Per-tenant HKDF-derived encryption keys. All secret material (ERP credentials, SSO secrets, API keys, message templates) is encrypted with a tenant-specific key derived from a root KMS-protected key via HKDF. Cross-tenant access is cryptographically prevented.
  • Per-tenant audit log capturing every record access, with the actor (user or service) and the request context.
  • Per-tenant rate limits for API and webhook surfaces.
  • Per-tenant backup snapshots restorable independently.

The schema-per-tenant choice was deliberate. Row-level multi-tenancy has bitten too many SaaS vendors with cross-tenant leak incidents; the additional operational complexity of schema-per-tenant is the right trade for B2B data sensitivity.

See the Trust Center and Security overview for the architectural detail.

Trade-offs

  • Migration complexity. Schema changes have to apply across every tenant schema. This is solved with disciplined migration tooling but it is a real operational cost.
  • Query routing. Connection pool management is more complex than single-schema systems.
  • Discovery overhead. Per-tenant noisy-neighbor diagnosis is harder than in a single-schema system because the data is partitioned.

These are real but worth paying for the isolation guarantee.

  • Tenant isolation. The broader principle that multi-tenancy implements.
  • HKDF (HMAC-based Key Derivation Function). The cryptographic primitive Factory uses to derive per-tenant keys.
  • Row-level Security (RLS). A Postgres feature for row-level tenant isolation; an alternative to schema-per-tenant.

Further reading