Short answer. A multi-tenant SaaS is one version of the code serving every customer, each in a sealed space called a tenant. The seal does not come from a checkbox: it comes from the tenant read from the login token, never from the URL, from a tenant identifier in every table with row policies in the database that filter even when the code forgets, and from tests that try to read another customer at every release. The many share one database; the two or three large accounts that require it get their own, moved by a data router without changing a line of code. Plans are tenant data the code reads, not different versions; quotas are enforced in the authorisation layer; migrations go out in waves and roll back. Sixteen weeks, two of them to write the tenant model before any code.
This guide is for the founder settled in France who wants to sell subscription software to pharmacies, schools or agencies in Algeria, the company whose vendor “duplicated the project” for each customer and now maintains fourteen copies, and anyone reading “multi-tenant architecture” in a quote without knowing what it must contain. It does not cover the subscription model or payment, described in the guide on launching a SaaS in Algeria in 2027; it covers what gets built so that a hundred customers fit on one installation without seeing each other.
What the figures say
The three texts that matter are public. Amazon Web Services, in the SaaS Lens of its Well-Architected framework, names three models: the silo, where each tenant has dedicated resources, its own database for instance, while sharing identity, onboarding and operations; the pool, “the more classic notion of multi-tenancy”, where tenants share compute, storage and messaging; and the bridge, the mixed mode where some parts are siloed and others pooled, with the regulatory profile of the data and the noisy neighbour risk steering a service towards silo. This vocabulary transposes as is: the question for an Algerian SaaS is not “silo or pool” but “what in silo, what in pool, and how to move from one to the other without a rewrite”.
PostgreSQL, the database we use for most SaaS, documents row-level security: once enabled on a table, “if no policy exists, a default-deny policy is used” and no row is visible; superusers and roles marked BYPASSRLS always bypass it, and so does the table owner unless it is forced; the documentation warns that integrity constraints bypass policies and can create covert channels. These details decide real security: a row policy enabled but not forced, with an application connected as owner, protects nothing. OWASP, in its 2023 API Top 10, puts broken object-level authorisation first: an attacker changes an identifier in the request and reaches someone else’s data; the defence is to check authorisation “on every function that accesses a record using an ID from the client”, to prefer random unpredictable identifiers, and to write tests.
The March 2026 case says it better than a rule. A security advisory published on 8 March 2026 for OneUptime, an open-source monitoring platform, describes an HTTP header the client could set itself that disabled tenant scoping; combined with a chosen project-identifier header, an ordinary user listed and modified other customers’ projects and read their creator’s password hash and reset token, up to taking over the account; scored 9.9 out of 10, fixed in the next version. On the Algerian side the ground is growing: according to the ministry’s startups director on Radio Algérie on 11 February 2026, more than 1,100 startups have been labelled since 2020, only about ten have ceased, a Scale-up label exists since December 2025 and the ministry aims at some fifteen labelled scale-ups in 2026; other sources give different counts, and we keep the ministry’s figure. Many of these startups sell software by subscription, and their architecture decides whether the hundredth customer costs as much as the first. What we did not find: a count of Algerian SaaS or a measure of their architecture; this guide speaks of what we build, not of a statistic.
The life of a request in a multi-tenant SaaS, in six moments
The architecture is not described by its database diagrams but by what happens to a request, from a user’s login to the log line that will feed their invoice.
Login issues a token carrying the user’s identity, the tenant they belong to and their role in that tenant; the login itself, by phone number or email, follows the guide on OTP authentication, and one user, an accountant for instance, can belong to several tenants and choose one at login. Tenant resolved is the moment that decides security: it comes from the token, or from a subdomain verified against the token, never from a URL parameter, a form field or a header the client can write; the March 2026 flaw is exactly a header the client could set. Context set attaches the tenant to the request and passes it to the database session as a variable; everything after, code, queues, files, sees it without asking again, and that is what prevents the forgotten line.
Authorisation checks three things and refuses if one is missing: the user’s role in this tenant, the plan the tenant subscribes to, and the quotas it has left; it is here, not in the screen, that the essential plan is prevented from exporting ten thousand rows. The database query touches tables that all carry a tenant column, with an index starting with it, and row policies enabled and forced: if a developer forgets the filter clause, the database adds it; the policy is a net, not the first line of defence, and it is tested with a role that is not the owner. Log and metering write every action with its tenant: usage, errors, storage, sends; this log feeds quota counters, the invoice in dinars and the screen that says which tenant consumes what, in the spirit of the dashboard guide.
The multi-tenant SaaS, in five layers
Behind the six moments, five layers, and the middle one is what distinguishes a SaaS from a collection of copies.
Identity and tenants: accounts, tenants, members, roles, invitations, and the rule that a user can belong to several tenants; a tenant has its administrators, who invite and remove without going through support. Plans and quotas: tiers, features enabled per tier, limits and counters; the plan is tenant data the code reads on every request, never a different version of the code, which is what lets you change a customer’s plan in a minute. The application: one version of the code for all, with the tenant as context in every request, every background job, every stored file; one update serves everyone, and tier-restricted features are switches, not code branches.
Data: a shared database with row policies for the many, a dedicated schema or database for the large accounts that require it, a router that knows where each tenant lives, and, whatever the model, backup, export and deletion of a tenant as unit operations. Operations: a single deployment, migrations in waves, per-tenant supervision and noisy-neighbour protection, work queues and rate limits per tenant; you know which tenant consumes what, and isolate it before it slows the others. The layers below decide the operating cost described in the guide on keeping an app alive; the layers above decide what can be sold, and the guide on SaaS in 2027 describes how it is sold.
«A SaaS is one version of the code and the tenant as context everywhere; everything else is a collection of copies nobody ends up daring to touch.»
A worked example
An example on market assumptions, with mechanics that are not assumptions: a vertical SaaS, two years after launch.
120 active customers on one installation: pharmacies, practices, shops, each with its users, data and settings, and none knows the others exist. 3 plans, essential, pro and enterprise: features, number of users, storage and message sends come from the plan; moving a customer from pro to enterprise is a write in its record, not a deployment. 2 customers on a dedicated database: a clinic group and a distributor who required it in the contract, for independent restore and visible separation; the data router moved them out of the shared database in one operation, without a line of code changing, and they pay the enterprise plan that covers this fixed cost.
Zero installs per customer is the result that depends on no assumption: one update a week, the same for all 120, deployed in minutes, with migrations tested on a production copy and rolled out in waves; one customer read-only for three minutes, never a hundred customers updated one by one. What the example shows: with the tenant as context, the hundred-and-twentieth customer costs a record in the database and a line in supervision; with a copy per customer, it costs a server, a deployment and a place on the list of things nobody dares touch. The assumptions to check at home: how many customers, what share will require its database, and how many users per customer; the project’s first two weeks answer them.
Six ways to house customers’ data
Six models, and one criterion to judge them: none must change the application’s code.
The shared database with protected rows is the default, from tens to thousands of ordinary-sized customers: a tenant column in every table, row policies enabled and forced, and a test at every release that tries to read another tenant and must fail. The schema per customer gives visible separation without a dedicated database; it requires repeating every migration on every schema and managing connections, and practitioners report it getting heavy beyond a few hundred customers; we keep it for cases where a customer wants to see their separation without paying for a database. The database per customer is AWS’s silo: large accounts, regulated data, a contract that requires it, the need to restore a single customer; fixed cost per customer, multiplied backups and migrations, and a router that knows which database serves which tenant.
The instance per customer goes further: their own server, their own domain, sometimes their own hosting country, but identity, updates and supervision stay shared, otherwise it is no longer a SaaS but a series of projects, and paying for hosting in foreign currency follows the guide on paying for cloud from Algeria. Mixed is the real case of most SaaS after two years: the many share, two or three large accounts are isolated, and only the data layer knows where each lives; it is AWS’s bridge, and it is what the worked example describes. Installed at the customer’s is rare, an administration or a group that refuses the cloud; it is an installable package, versions to track and different support, to be billed as such. The first row covers most Algerian SaaS in 2027; the fifth is what they become when a large account signs.
Six situations that break a multi-tenant SaaS
Six situations we see on the SaaS we take over, and what the architecture does against each.
The cross-customer leak costs trust: a user changes an identifier in the URL and sees another customer’s invoices; the tenant read from the token, the check on every object, row policies as a net, random identifiers and an automated test that attempts the leak at every release make it improbable, and that is the order in which OWASP recommends them. The noisy neighbour: a customer launches a two-million-row export at ten and slows everyone else; work queues per tenant, rate limits, asynchronous exports delivered by link, quotas per plan, per-tenant alert. The migration that breaks a customer: a schema change passes for 119 customers and fails on the 120th with old data; migrations tested on a production copy, deployed in waves, reversible, the customer read-only during the migration.
The customer who wants their data leaves, or wants a copy, or wants everything erased; full export per tenant in a readable format, deletion of a tenant in one logged operation, and the delay written in the contract, which is also what the guide on the app stuck with a vanished developer asks for your own data. The large account that demands its database signs on condition of having its database, its domain, sometimes its hosting country; the data router moves it without touching the code, and the enterprise plan pays the fixed cost. The plan that limits nothing: the essential plan consumes as much storage and sending as the enterprise plan, and costs rise with the customers who pay least; per-tenant counters fed by the log, limits enforced in the authorisation layer, overage visible to the customer with the button to change plan. The first costs trust, the other five cost money or customers, and none is repaired in an emergency.
«The tenant comes from the token, and from nothing the client can write.»
Seen elsewhere: AWS, PostgreSQL, OWASP, OneUptime, and what transposes
Four public texts say the essentials. AWS gives the vocabulary, silo, pool, bridge, and the rule that the decision is made resource by resource and not for the whole system; what transposes is deciding in the first week what to share and what to isolate, and building the data router that will let you change your mind for one customer without a rewrite. PostgreSQL says what a row policy is worth: everything is denied by default once enabled, superusers and the owner pass through unless forced, and integrity constraints can leak; what transposes is that the application connects with a role that is not the owner, that the policy is forced, and that a test verifies it with that very role.
OWASP says where to look: the object identifier supplied by the client is the first cause of cross-customer leaks, and the answer is a check on every access, unpredictable identifiers and tests; what transposes is that “multi-tenant” in a quote must come with “cross-tenant leak tests at every release”. The OneUptime case of March 2026 shows the shape the error takes in real life: not a badly designed database, but a header the client could set that disabled the filtering; what transposes is the rule of moment 02, the tenant comes from the token and from nothing else. What these texts do not say: what share of your customers will require their database, and at what price you sell it; the week-12 pilot and the guide on SaaS in 2027 answer that.
The rules of a multi-tenant SaaS that lasts
Six rules, written in the first week and reread at every release. One version of the code: plans are switches read from the tenant’s record, never branches; a feature requested by one customer is built for all and enabled for them. The tenant comes from the token, or from a subdomain verified against the token, and from nothing the client can write. Every table carries the tenant, the index starts with it, and row policies are enabled, forced and tested with the application’s role. A leak test at every release: a user of tenant A tries to read, modify and delete in tenant B through every entry point, and the release is refused if they succeed once. Per-tenant operations exist before the first customer: export, deletion, restore, move to a dedicated database. Accounts, code, domains and hosting are in the company’s name, not the vendor’s, and the code is delivered in a repository you own.
A seventh rule concerns the specification: “multi-tenant architecture” is not a requirement, it is a sentence; the requirement reads “one version of the code serves all customers; the tenant is resolved from the token; every table carries tenant_id with forced row policies; an automated cross-tenant leak test is part of acceptance; export, deletion and move of a tenant to a dedicated database are delivered operations; plans and quotas are enforced in the authorisation layer”, and it is checked at acceptance, as the guide on the specification recommends. A quote that writes “multi-tenant” without these six lines has priced a single-customer application that will be copied.
Six vertical SaaS, what is shared and what is isolated
Six SaaS we often build, and for each the data model chosen in the first week.
- The SaaS for pharmacies or shops. Shared database, one tenant per pharmacy, three plans; integration with each customer’s till and accounting follows the guide on integrating existing software, with one connector per tenant.
- The SaaS for private schools. Shared database, one tenant per school, parents who belong to several tenants when they have children in two schools; full export required at every year end.
- The SaaS for clinics and practices. Shared database for practices, dedicated database for groups that require it; forced row policies and per-tenant access log, because this is health data.
- The SaaS for real-estate agencies. Shared database; an owner in France can be a member of several agencies; the owner space described in the dedicated guide is a view filtered by tenant and by property.
- The SaaS for distributors. Shared database for most, dedicated instance for the importer who has its ERP and its domain; each distributor’s B2B portal, described in the dedicated guide, is a tenant with its retailers as members.
- The SaaS with an AI agent. One WhatsApp agent per tenant on the same platform, number and templates in each customer’s name, knowledge and logs separated per tenant; the agent’s architecture follows the dedicated guide.
The 2027 calendar
The calendar is that of a sixteen-week multi-tenant SaaS, two weeks without code and two of pilot with five real customers on the same installation.
Weeks 0 to 2 write the tenant model: what is a tenant, who is a member, which roles, which plans with which limits, which default data model and which path to the dedicated database; a SaaS whose model is written after the code becomes a collection of copies. Weeks 2 to 4 build identity: tenant sign-up, invitations, roles, login by phone or email, membership of several tenants. Weeks 4 to 8 build the core business with the tenant everywhere: tenant column in every table and queue, forced row policies, and the leak test that runs at every release from the first. Weeks 8 to 10 set plans, quotas and billing: tiers, switches per tier, counters, overages, invoices in dinars and reminder before the due date, on the model described in the guide on SaaS in 2027.
Weeks 10 to 12 install operations: migrations in waves, per-tenant backup and export, per-tenant supervision, rate limits, and the data router tested by moving a test tenant to a dedicated database and back. Weeks 12 to 14 are the pilot: five real customers on the same installation, usage measured per tenant, and the first large account isolated if one of the five requires it; it is the first moment two customers really share the same database. Weeks 14 to 16 open: self-service sign-up, automatic onboarding, first paid plan, supervision as routine. Startups aiming for the label, described in the guide on the startup label, do better arriving at the file with this pilot done than with a mock-up.
What makes a multi-tenant SaaS fail
The SaaS we take over almost always fail for one of these reasons.
- One copy of the code per customer. The third customer got their feature, the fourteenth has their version; nobody can update everything any more.
- The tenant in the URL or a header. One identifier changed, and one customer sees another; that is the March 2026 flaw, and it is only fixed by rewriting authorisation.
- Row policies enabled but not forced. The application connects as owner and passes through; security exists only on paper.
- No leak test. The leak is discovered when a customer posts it on social networks, not at acceptance.
- The plan as a version of the code. Three plans, three branches, and every fix is made three times.
- No per-tenant export or deletion. The first customer who leaves takes three weeks to get their data and tells all the others.
- The large account handled by a copy. The SaaS is duplicated for them; six months later they have their own version and their own bugs.
Frequently asked questions
The questions we receive from founders settled in France, companies taking over copied software and teams comparing quotes.
- Multi-tenant or one installation per customer: which to choose?
- Multi-tenant for any SaaS sold by subscription: one version of the code, the tenant as context, and a data router that lets you give a dedicated database to the two or three customers who require it. The installation per customer is a different product, to be billed as such, and it must never be the answer to a feature request.
- Shared database or database per customer?
- Shared database with forced row policies by default, for the many; dedicated database for large accounts, regulated data and contracts that require it, moved by the data router without changing the code. Most Algerian SaaS end up mixed after two years, and the architecture must plan for it from the first week.
- How can we be sure one customer does not see another’s data?
- Through four layers that add up: the tenant read from the token and never from the request, the authorisation check on every object, row policies enabled and forced in the database with an application role that is not the owner, and an automated test that attempts the leak at every release. A quote that does not mention the test has not planned the other three.
- A customer asks for a feature the others do not want. Do we copy?
- No: the feature is built in the single version and enabled for that customer by a plan or tenant switch. If it is truly specific, it is billed as development and enabled for them alone; the code stays one. Copying is what turns a SaaS into fourteen projects.
- What happens when a customer leaves?
- They receive a full export of their data in a readable format, and their tenant is deleted in one logged operation within the delay written in the contract. These two operations exist before the first customer; they are the proof that the data was properly separated.
- How long to build a multi-tenant SaaS?
- Sixteen weeks for a vertical SaaS, two of them to write the tenant model before any code, four for the core business with the tenant everywhere, and two of pilot with five real customers on the same installation. The subscription model and payment are prepared in parallel.