Subdomains Are the Easy Part of Multi-Tenant SaaS

Introduction

Multi-tenant SaaS means many customers running on the same infrastructure instead of each getting their own deployment. The part that gets the most attention — subdomains, SSO, onboarding flows — is genuinely important but not where the expensive mistakes happen. The expensive mistake is picking a tenant data model without understanding what it costs you later, because changing it after you have real customers on it is one of the more painful migrations in software.

Where Tenant Data Actually Lives

Three real options, each with a genuine tradeoff:

• Shared tables, tenant_id column. Every tenant's rows live in the same tables, filtered by a tenant_id on every query. Cheapest to run, simplest to migrate schema changes across all tenants at once — and the riskiest, because a single missing WHERE clause can leak one tenant's data into another's results. Fine for low-sensitivity data and a large number of small tenants; a hard sell for anything regulated.
• Schema-per-tenant. One database, one schema per tenant. Better isolation than shared tables without the operational cost of separate databases — but schema migrations now have to run once per tenant, and at a few hundred tenants that stops being trivial. Often ends up the worst of both worlds: real operational overhead without the strongest isolation guarantee.
• Database-per-tenant. Full separation — the strongest isolation, the cleanest story for compliance and enterprise security reviews, and the most expensive to operate at scale. Backups, migrations, and monitoring all multiply by tenant count. This is where large enterprise customers often want to land, and where a startup with thousands of small tenants can't afford to.

The honest framework: default to shared tables with tenant_id while you have few, small tenants and nothing regulated in the data. Move specific high-value or compliance-sensitive tenants to their own database as a deliberate exception, not a wholesale migration. Trying to guess the "right" model up front for a product that doesn't have customers yet usually costs more than picking the simple option and re-architecting the one tenant that actually needs isolation later.

Getting Users In

Role-Based Access Control (RBAC) ties permissions to roles rather than individual users — an account admin sees and does more than a regular member, without hand-managing permissions person by person. Design the roles around what your product actually needs people to do, not a generic admin/editor/viewer template that doesn't map to your domain.

Single sign-on (SSO) lets an admin define who from their organization gets access and lets those users sign in through their company's identity provider — Google, Microsoft, Okta — instead of a separate password for your app. For B2B SaaS this is frequently a hard requirement from enterprise buyers, not a nice-to-have; check it before it blocks a deal, not after.

Invitations and onboarding round it out: a one-time email link to verify identity and set a password, then getting a new user into the right groups and connected to whatever third-party services (Slack, Google Drive) the account actually uses. None of this is exotic, but skipping any piece of it is exactly where new tenants get stuck in week one.

Routing Requests to the Right Tenant

The most common approach: give each account a subdomain (acme.yourapp.com) and route incoming requests based on it. Each tenant record needs a primary key, an account name, and a subdomain — plus whatever else your product needs per account. Making this work means either a wildcard TLS certificate covering all subdomains or issuing certificates per tenant, and configuring your web server to route based on the subdomain in the request. Wildcard certificates aren't free and the server configuration isn't always trivial, but compared to the tenant-data-model decision, this part is genuinely the easy half.

Conclusion

Subdomains, SSO, and RBAC are all solvable with well-documented patterns. The tenant isolation model is the one decision worth slowing down for, because it's the one that's expensive to unwind once real customer data is sitting inside it. This is exactly the kind of architectural call Taliferro walks through before writing code on a multi-tenant product — not because it's exotic, but because it's the one mistake that's genuinely hard to undo later.

Tyrone Showers