Decisions5 min read
Multi-tenant SaaS explained for non-technical founders
By Sannan MalikPublished
Short answerMulti-tenant SaaS means one platform serves many customer organisations, called tenants, while each one sees only its own data, users, branding and settings. Data can be separated with a tenant id on every row, a schema per tenant or a database per tenant. For most new products I start with a shared database and a tenant id, enforced by the database itself, and move a tenant out only when there is a concrete reason.
A tenant is a customer account, not a user
A tenant is one organisation that pays for your product. A clinic, a school, a brokerage. Each tenant has many users, and those users belong to that tenant only.
Single-tenant means every customer gets their own copy of the software, installed and updated separately. Multi-tenant means one copy serves everyone. You deploy a fix once and every customer has it. You run one set of servers. The price of that convenience is that the walls between customers have to be designed in, because they are no longer separate installations.
Three ways to keep tenants' data apart
In PostgreSQL, the database I use for SaaS, there are three common patterns. A schema is a named container inside a database, and PostgreSQL's documentation notes that the same table name can be used in different schemas without conflict, so each tenant can have its own set of identical tables.
| Model | How data is kept apart | Where it fits | What it costs you |
|---|---|---|---|
| Shared database, tenant id | Every row carries a tenant id; the database filters by it | Most new SaaS products with many small or mid-sized customers | Cheapest to run and update; separation depends on the rules being on every table |
| Schema per tenant | Each tenant has its own copy of the tables in its own schema | A modest number of tenants who need some per-customer changes | Every database change has to run once per schema |
| Database per tenant | Each tenant has a separate database | Large customers whose contracts require separate storage, or whose load would slow others | Highest hosting and maintenance cost; backups, upgrades and monitoring multiply |
What actually stops one customer seeing another
With a shared database, the risk is a query that forgets the tenant filter. One missed line and a customer sees another customer's records. I do not rely on every developer remembering it.
PostgreSQL has row security policies for this. Once row security is enabled on a table, every normal read or change of a row must be allowed by a policy, and if no policy exists, the documentation says a default-deny policy applies, so no rows are visible. I write a policy that matches each row's tenant id to the tenant of the current session. A forgotten filter then returns nothing, not someone else's data.
Two details matter, and both come from the same documentation page. The table's owner is typically not subject to these policies unless the table is set to force them, and superusers and roles with the BYPASSRLS attribute always bypass them. So the application must connect as an ordinary role, never as the owner or a superuser. I also write tests that sign in as one tenant and try to read another tenant's records.
Separation has two layers. My Forex CRM case study is a multi-tenant broker architecture on PostgreSQL with deny-by-default access and role-based access control, so walls exist between brokers and also between roles inside each broker. A support agent and a finance manager at the same broker do not see the same screens.
Custom domains, white-label branding and per-tenant settings
White-label means each tenant presents the product as its own. In the Forex CRM, each broker is resolved by its own domain: when a request arrives, the platform reads the domain, finds the broker it belongs to, and loads that broker's logo, colours and settings. The infrastructure is shared. The data is not.
Custom domains add a setup step for each tenant. They point their domain at the platform, and a security certificate has to be issued for it. That is worth automating once you expect more than a handful of tenants.
Settings and billing are the other half of a tenant. Before I design the data model, I ask founders to answer these:
- What is configured per tenant: name, logo, colours, domain, language, currency, time zone?
- Which features are switched on per plan, and which limits apply, such as users, records or storage?
- Is billing per tenant, per user inside a tenant, or by usage?
- Who inside a tenant can invite users, change settings and see invoices?
- What happens to a tenant's data when they stop paying or leave?
- Does any customer need its data held separately because their contract says so?
Which model I start with, and what I build
My rule: start with a shared database, a tenant id on every table and row security policies enforced by PostgreSQL. Move a single tenant to its own database only when something specific forces it, such as a contract that requires separate storage or one customer whose load slows the others down. I rarely choose schema per tenant for a new product, because every change to the tables then has to be run once per tenant.
Starting shared is not a dead end. Because every row already carries its tenant id, moving one tenant's data to a dedicated database later is a contained job. Going the other way, from many separate databases back into one, is much harder.
SaaS platforms are custom software, so I give a fixed quote after scoping the tenant model, plans, roles and the admin tools your own team needs to run the product. If you have a product idea with several customer organisations in it, send me who the tenants are and how you plan to charge them, and I will tell you which model I would start with.
Questions
- Is a shared database safe for customer data?
- It can be, when separation is enforced by the database rather than by each query. With PostgreSQL row security policies, a query with no matching policy returns no rows, and tests check that one tenant cannot read another's records.
- Can each customer use their own domain?
- Yes. The platform looks up the tenant from the domain of each request and loads that tenant's branding and settings. Each domain needs a DNS change and a certificate, which can be automated.
- Can an existing single-customer app become multi-tenant?
- Often, but it changes the data model, because every table needs a tenant id and access rules. I start with an audit and a staged plan rather than a rewrite.
Sources
Platform rules and fees in this article were checked against these official pages on 8 November 2026. They change, so confirm before you rely on them.
Sannan Malik is a software architect and product builder with 8+ years in software, CEO of Alpha Notic FZC and a Certified Scrum Product Owner. He builds mobile apps and business software for companies in the UAE, UK and US.
