Building multi-tenant SaaS: architecture decisions

A multi-tenant SaaS serves many customers (tenants) from one product. Done well, you run one codebase, deploy once and every customer gets the improvement. Done badly, one customer sees another customer's data, one large customer slows everyone down, or every enterprise deal turns into a fork of the code.

Most of these outcomes are decided early, in a handful of architecture decisions. Here are the ones we work through with clients, and what we learned building multi-site platforms such as Smart DigiBuild, which we develop for Four Corners Technology.

1. How tenants' data is separated

There are three common models:

• Shared database, shared tables: every row carries a tenant ID. Cheapest to run and simplest to operate, but isolation depends on every query filtering correctly.
• Shared database, separate schema per tenant: better isolation and easier per-tenant export, at the cost of more complex migrations as the number of tenants grows.
• Separate database per tenant: strongest isolation and easy per-tenant backup, restore and data residency, but higher cost and more operational work.

For most B2B products we start with shared tables and a tenant ID, protected by database-level enforcement such as PostgreSQL row-level security, so a forgotten filter in the code cannot leak data. Large or regulated customers can later move to their own database. Design the code so this is possible from day one: tenant access goes through one data-access layer, never ad hoc queries.

2. Where tenant context comes from

Every request must know which tenant it belongs to. Typical sources are the subdomain (customer.app.com), a claim in the login token, or an explicit tenant switch for users who belong to several organisations. Resolve the tenant once, early in the request, and pass it through explicitly. Background jobs, queues, caches, file storage and search indexes need the tenant too. Cache keys and storage paths without a tenant prefix are a classic source of leaks.

3. Authentication and roles

B2B customers expect more than email and password:

• Organisations and roles: admins invite users, assign roles and remove leavers themselves.
• Single sign-on: larger customers want to log in with Microsoft Entra ID, Google or their own identity provider via SAML or OpenID Connect.
• Audit logs: who changed what and when, visible to the customer's admins.

Use an established identity service or library rather than building this yourself, and model roles per tenant from the start.

4. Configuration instead of custom code

Every customer will want something slightly different. If each wish becomes an if-statement with a customer name, the product becomes unmaintainable. Plan for configuration:

• Feature flags per tenant and per plan.
• Settings for workflows, fields, notifications and branding.
• Extension points such as webhooks and an API, so customers can integrate without changes to the core.

Our rule: if two customers need it, it becomes a configurable feature. If only one needs it, look for an integration first.

5. Plans, limits and billing

Decide early how you charge: per user, per location, per usage or a flat fee per plan. The product must then know each tenant's plan, enforce limits (users, devices, storage, API calls) and measure usage. Payment providers such as Stripe handle invoices and subscriptions, but the limits and usage metering live in your product.

6. Noisy neighbours

In a shared system, one tenant's large import or heavy report can slow everyone else down. Protect against it with rate limits per tenant, background queues for heavy work, query timeouts and monitoring that shows load per tenant. When a tenant consistently needs much more, that is a reason to move it to dedicated resources, ideally as a higher-priced plan.

7. Data residency and compliance

German and European customers often ask where their data is stored, who can access it and how it is deleted. Answer these in the architecture:

• Hosting in an EU region, and documented subprocessors.
• A data processing agreement (Art. 28 GDPR) for every customer.
• Per-tenant export and deletion, so you can meet access and erasure requests and handle the end of a contract.
• Backups with defined retention, and a tested restore for a single tenant.

8. Migrations and releases

With one codebase for everyone, a broken release affects every customer at once. Use backward-compatible database migrations (expand first, contract later), automated tests including tenant-isolation tests, staged rollouts with feature flags, and a fast rollback. If you have separate databases per tenant, automate migrations across all of them and monitor their progress.

9. Observability per tenant

Logs, metrics and traces should carry the tenant ID. Then support can answer "why is it slow for customer X?" in minutes, you see which tenants use which features, and you notice when one tenant hits errors after a release.

Conclusion

Multi-tenancy is not a feature you add later. Data isolation, tenant context, roles, configuration, limits and compliance shape the codebase from the first sprint. Getting them right early keeps the product to one codebase, even as customers and their wishes grow. We design and build multi-tenant B2B platforms, from MVP to scale. See our custom software development services or read how to launch an MVP in 8 weeks.

Discuss your SaaS architecture