Multi-Tenant Architecture: The Guide for SaaS Founders

The term comes up in every technical conversation about subscription software: multi-tenant architecture. Behind it lies a simple question: how can a single platform serve hundreds of customers while guaranteeing that each one sees only their own data? This guide explains the three possible approaches, their trade-offs and the questions to ask your team or vendor, without unnecessary jargon.

Tenant, multi-tenant: what are we talking about?

A tenant is a customer of your SaaS: a company, an agency, a practice, with its users and data. A multi-tenant architecture hosts all these tenants on the same application and infrastructure, as opposed to a separate installation per customer (*single-tenant*). This sharing is what makes the SaaS model profitable: one version to maintain, one deployment, pooled hosting costs.

The downside of sharing is risk: an error in a query can show one customer's data to another. The whole of multi-tenant architecture consists of making that error impossible, or at least very hard.

The three data isolation models

1. Shared database, shared tables

All customers share the same tables; every row carries a tenant identifier. It's the simplest model to operate and the cheapest: one database, single migrations, global backups. It does demand absolute rigour: every query must filter by tenant, without exception. Modern databases such as PostgreSQL offer mechanisms (row-level security policies) that apply this filter automatically, which greatly reduces the risk of an oversight.

2. Shared database, separate schemas

Each customer has its own schema (set of tables) within a shared database. Isolation is stronger, per-customer exports and deletions are simple. The price: migrations to apply on every schema and complexity that grows with the number of customers.

3. One database per customer

Maximum isolation, predictable performance, the option to host certain customers in a specific region or with a specific provider. It's the model some large accounts or regulated sectors require. In return, operations are heavy: dozens or hundreds of databases to migrate, monitor and back up. It's rarely justified for an MVP.

Which model for a SaaS that's just starting?

In the vast majority of cases, the first model (shared database, tenant identifier on every table, row-level security policies) is the right choice: simple, economical, and sufficient up to thousands of customers. The essential thing is to design the data model with the tenant from day one: adding that notion afterwards to existing tables is a long and risky operation.

Beyond the database: what multi-tenancy involves

• Accounts and roles: a user belongs to a tenant (sometimes several), with permissions specific to each workspace.
• Files and documents: uploaded files must be stored and protected per tenant, not just hidden behind a hard-to-guess URL.
• Per-customer configuration: logo, currency, language, specific business rules, without duplicating code.
• Billing: each tenant has its plan, trial, invoices and usage limits.
• Performance: a very active customer must not slow down the others (rate limits, queues for heavy processing).
• Export and deletion: a customer must be able to retrieve their data and request its erasure, which is also a data protection requirement.

Security: the controls to put in place

1. A tenant filter applied at the database level or in a single access layer, never scattered across screens.
2. Automated tests that attempt to access another tenant's data and must fail.
3. Activity logs (who did what, when, in which workspace).
4. Tested backups, with the ability to restore a single customer if needed.
5. A security review before launch and at every major change.

We cover personal data protection, including Moroccan and European obligations, in SaaS security and data protection in Morocco.

Scalability: growing without rebuilding everything

A well-designed multi-tenant architecture grows in stages: one server and one database at the start, then read replicas, a cache, asynchronous processing and, if a large account requires it, the ability to move a tenant to dedicated infrastructure. What matters is that these stages are possible without rewriting the application. That's what we aim for in every SaaS development project: simple foundations at launch, but ready for what comes next.

Concrete example: the data model of an appointment SaaS

To make things tangible, imagine an appointment-booking SaaS sold to practices. Each practice is a tenant. The data model has an organisations table (the tenants), a users table attached to an organisation with a role, then the business tables: patients, practitioners, appointments, invoices. Each business table carries an `organisation_id` column. A row-level security policy, defined once in the database, enforces that every read or write concerns only rows belonging to the logged-in user's organisation. A developer who forgot the filter in a query would get an empty result, not another practice's data.

Files (scanned prescriptions, documents) are stored in object storage, in a folder per organisation, and served through time-limited signed links. Heavy tasks (bulk reminders, exports) go through a queue that processes organisations one at a time, so a practice exporting ten years of history doesn't block the others.

Linking plans, limits and multi-tenancy

The tenant is also the billing unit. Each organisation carries its plan, its trial end date, its state (active, in grace period, suspended) and its limits (number of practitioners, appointments per month, users). The application checks those limits in the right place: when creating a practitioner, not in every screen. When a customer changes plan, the update touches a single row. This centralisation makes discounts, trial extensions and special offers possible from a back office, without touching the code.

Large accounts and the dedicated-instance request

Sooner or later, an important customer will ask for "their own server" or hosting in a specific country. With an architecture where the tenant is everywhere and configuration (database, storage, region) is defined per environment, answering that request means deploying a second instance of the same application with its own database, for a single customer. The code stays identical; only the configuration changes. Without that discipline, the request turns into a months-long project. Price the service accordingly: a dedicated instance costs more to run than a tenant on the shared platform.

Migrating a single-customer application to multi-tenancy

1. Add an organisations table and create the existing customer as the first tenant.
2. Add the tenant column to every business table, fill it for existing data, then make it mandatory.
3. Attach each user to their organisation and introduce roles.
4. Put the structural filter in place (row-level policies or a single access layer) and the isolation tests.
5. Move hard-coded configuration (logo, rules, document templates) to per-organisation settings.
6. Add per-organisation billing and the self-service sign-up journey.
7. Rehearse the migration on a test environment, then switch over.

This process is detailed, with the business and commercial aspects, in turning internal software into a SaaS.

Questions to ask your vendor

• How is each customer's data isolated, and how is that isolation tested?
• What happens if a customer asks for an export or deletion of all their data?
• How is a very active customer prevented from degrading performance for the others?
• How will data model changes be applied once customers are in production?
• Can a customer be hosted in a particular region or with a particular provider if they require it?

Preparing a SaaS and want to validate its architecture before building? Let's talk: one conversation is often enough to rule out the choices that cost dearly later.