SaaS multi-tenant boundaries without the drama

Early SaaS products often share one schema “for speed.” That works until a customer asks for export guarantees, residency, or a hard delete — and suddenly every query is a liability audit waiting to happen.

Tenancy is not a migration you schedule for “later.” It is a product boundary you either chose or accidentally inherited.

Start with a tenancy model you can explain

Pick one and write it down before you optimize queries:

• Shared DB, tenant column — cheapest, highest blast radius.
• Schema-per-tenant — clearer isolation, heavier migrations.
• DB-per-tenant — strongest boundary, ops cost rises fast.

There is no universally correct answer. There is an answer your support and compliance story can survive when someone asks on a call: “Can customer A ever see customer B’s data?”

If the honest answer is “only if we forget a filter,” you already know what to fix first.

Enforce at the edge of the domain

Tenant context belongs in middleware / gateway, not sprinkled as optional filters in every repository method.

Optional filters get forgotten. Forgotten filters become incidents. Incidents become “we need a rewrite” slides — which is expensive therapy for a missing middleware check.

Plan the escape hatch

You will need to move a noisy tenant, restore a single customer, or isolate a regulated account. If that path is not rehearsed, your tenancy model is incomplete on paper only.

Run the drill once: export one tenant, restore to a sandbox, prove no cross-tenant reads. Boring rehearsal beats exciting production discovery.

Takeaway

Tenancy is a product boundary, not a SQL habit. Design for the support ticket you have not received yet.

The schema you pick at ten customers is the story you tell at a hundred — unless you planned the escape hatch early.