Multi-tenant B2B SaaS
A reference architecture for multi-tenant B2B platforms.
- Tenant isolation
- Row-level security
- Per-tenant configuration
- Operational boundaries
Multi-tenant is easy to draw on a whiteboard and hard to live with. The shortest path — one database, one schema, a tenant_id column on every table — works until a paying customer asks for data residency, or a noisy neighbour starves the rest, or an engineer ships a query that forgets the where clause. The reference architecture below is the shape we reach for when a B2B platform needs to grow into those conversations without rewriting itself.
Tenancy is a boundary, not a column.
We treat tenancy as a first-class boundary on three layers — data, request, and operator. At the data layer, row-level security policies enforce isolation inside Postgres rather than trusting application queries; the database refuses to leak rather than the application remembering not to. At the request layer, every authenticated request carries a verified tenant claim, and middleware refuses to dispatch without it. At the operator layer, support tools require a tenant scope to be selected before any read or write, and every action is logged with the operator identity and the tenant scope it was taken under. White-label branding, regional pinning, and per-tenant rate limits ride on the same boundary.
Tenancy is a boundary, not a column.
Three-layer isolation · data · request · operator- Lead ArchitectMirko Vanzo
- PatternReference architecture · keelroot studio
- Year2025
- PostgreSQL · row-level security
- TypeScript · Node
- Tenant-scoped middleware
- Per-tenant configuration loader
- Audit logging at the operator layer