TL;DR — There are three production-tested multi-tenant patterns: shared database, schema-per-tenant and database-per-tenant. Most products should start at shared and move only when a real isolation, compliance or noisy-neighbor problem forces the change. White-label is orthogonal to all three.
Every white-label SaaS pitch starts the same way: “We need multi-tenant from day one.” Usually what the team means is “We want each customer to see their own brand.” Those are two different problems with two different solutions. Conflating them is the most expensive architectural mistake in this space.
Pattern 1: Shared database, tenant_id column
One database, one schema, every table carries a tenant_id. Every query filters by it. Authorization middleware injects the current tenant context.
Pros: simple to build, cheap to operate, easy to migrate. Cons: all tenants share the same blast radius — one bad query plan can affect everyone. Compliance teams hate it.
Use when: early-stage product, tenants are similar in size, no regulatory isolation requirements. Almost every product should start here.
Pattern 2: Schema-per-tenant
One database, one schema per tenant. Tables exist N times, once per tenant. Provisioning creates a schema; deprovisioning drops it.
Pros: strong logical isolation, easier per-tenant backups, schema migrations can roll out per tenant. Cons: migrations become N times more expensive; connection pooling needs care; some ORMs hate it.
Use when: you have tens to low-hundreds of tenants, tenants want clear data separation, you need per-tenant migration windows.
Pattern 3: Database-per-tenant
Each tenant gets a dedicated database instance, often in a dedicated region. Highest isolation, highest operational cost.
Pros: regulatory isolation, easy per-tenant scaling, true blast-radius separation. Cons: N databases to monitor, backup, patch and migrate; deployment automation must be excellent or operations collapse.
Use when: tenants are large and few (enterprise customers, healthcare, financial services), or compliance regimes require per-customer isolation.
Where Nexia Academy landed
We started Nexia Academy on Pattern 1 (shared database). It carried us through the first three tenants comfortably. We moved to Pattern 2 (schema-per-tenant) when we hit two specific pressures: one tenant requested per-tenant content versioning that did not interleave with others, and another wanted backup snapshots they could download independently. Pattern 2 solved both without the operational cost of Pattern 3.
The white-label layer is separate
White-label — custom domains, per-tenant logos, per-tenant theme colors, per-tenant email templates — sits on top of any of the three patterns. Build it as a configuration layer keyed by tenant_id with sensible defaults. Resist the urge to ship per-tenant code branches; they become a maintenance disaster within a year.
The migration trap
Moving from Pattern 1 to Pattern 2 mid-flight is painful but doable. Moving from Pattern 1 or 2 to Pattern 3 is significantly harder. If there is a meaningful chance you will need per-tenant databases later, design the data-access layer so the tenancy decision is centralized — one helper function decides which connection to use. Then the migration is plumbing, not surgery.
Frequently asked questions
Which tenancy model should I start with?
Start with shared database + tenant_id columns. It is the simplest to build and operate, and it covers 80% of products. Move to schema-per-tenant only when you hit isolation, compliance or noisy-neighbor problems.
How does white-label differ from multi-tenant?
Multi-tenant is an architecture choice (how data is isolated). White-label is a product choice (whether the UI carries the customer brand, on the customer domain, with no T-Square branding). The two are independent — you can ship a multi-tenant product without white-label, or a white-label product on a single tenancy model.
Working on something similar?
T-Square is an independent software engineering studio. We architect, build and operate production-grade systems for learning, AI and custom software products. Talk to a senior engineer if you’d like a second opinion on your architecture or roadmap.