Multi-tenant SaaS: a namespace per customer or a row per customer?

Sooner or later, every SaaS faces the same question: how do we separate customers from each other? The answer determines cost, security, operations – and which customers you can win at all. There are two basic models, and the right answer is usually a mix.

Model A: One row per customer

All customers share one application and one database. Every table carries a tenant_id column, and every query filters on it. This is the model used by Slack, Notion and most B2B tools.

Strengths: One deployment for everyone, one schema, one database. New customers cost nothing but a row. A bug fix reaches everyone immediately.

Weaknesses: One forgotten filter shows customer A the data of customer B. One slow query from a large customer slows everyone down. A customer who wants their data in a dedicated data center or a dedicated database is out of luck. And a backup is always a backup of everyone.

Model B: One namespace per customer

Every customer gets their own instance of the application: their own namespace in the cluster, their own database on the managed instance, their own buckets, their own hostname. This is the model agencies use to run one CMS per customer and SaaS vendors use to serve enterprise customers.

Strengths: Hard separation. A faulty query cannot hit someone else’s rows, because they do not exist in this database. A customer can get their own version, their own domain, their own backup. A customer who cancels is torn down cleanly.

Weaknesses: Every customer is a deployment. A release has to be rolled out n times. Without automation, this becomes a full-time job from twenty customers on.

Which model fits which customer?

Why does the mix win in practice?

Most successful SaaS vendors run both. The self-service plan runs as a row per customer: thousands of small customers, one deployment, minimal cost. The enterprise plan runs as a namespace per customer: their own instance, their own database, their own domain, their own contract on data residency.

The trick is that the application has to support both without maintaining two codebases. An instance with one customer is simply the special case of an instance with many. The tenant_id stays; in the enterprise instance it just has a single value.

What does model B need so it does not hurt?

A namespace per customer never fails because of Kubernetes – it fails at onboarding. If you create a database, generate a password, set a record and install a Helm release by hand for every customer, you have a script after the tenth customer and a problem after the thirtieth. Three things must be automated:

1. Provisioning as a repeatable pipeline: database, buckets, domain and workload in a fixed order, with a rollback if step four fails.
2. Distributing releases across all customers, with visibility into which customer is on which version.
3. Teardown with a backup first. A customer who cancels may still want their data, and you do not want to have deleted it by accident.

This is exactly what tenant pipelines in Clusterward are for: the per-customer stack is described once, every customer is a run, and offboarding backs up first and tears down afterwards.

A word on the database

Model B does not require one database instance per customer. A managed instance holds hundreds of databases, each with its own role and its own password. That is the middle ground between cost and separation: the instance is shared, the data is not. How roles, privileges and additional users work here is explained under Managed databases.

An example: a CMS vendor grows

A vendor runs a content management system as SaaS. The first hundred customers are rows: one database, one deployment, one domain with a path or subdomain per customer. It works, and the cost per customer is negligible.

Then a public authority comes along. It wants its content in a dedicated database, its own domain, its own backup and the assurance that no other organization uses the same instance. In the row model, that is a custom build. In the namespace model, it is just another run of the same pipeline, only with a different plan. The vendor introduces the second plan without changing the code: the authority’s instance is an instance with exactly one customer.

Two years later, the vendor has three hundred row customers and forty namespace customers. The forty bring in more revenue than the three hundred. And running the forty takes less attention than the one custom build used to, because every instance looks the same: same pipeline, same chart, same version, just a different customer.

Three mistakes when moving to namespaces

1. Deriving the namespace name from the customer name. When the customer is renamed, the name points nowhere and the next deployment creates a second namespace. The name should be set once and stored, never recomputed.
2. The password in the onboarding log. If you write the customer’s database password into the run, it ends up in every log and every backup of that run. It belongs in database management and is only read at runtime.
3. No rollback. If step four fails, the database, bucket and record from steps one to three are left behind. Every step needs its reverse, and the rollback runs backwards.

Conclusion

Start with rows if you expect many small customers. Plan for namespaces as soon as the first customer asks for a dedicated database or their own domain – and that happens sooner than you think. Build the application so that both are the same code. And automate onboarding before you need it.

Which model fits your app? Give us a short description of your application and your customers. We will tell you whether rows or namespaces fit better and what onboarding looks like as a pipeline. Discuss your tenancy model →

Sources and further reading

• Kubernetes docs: Multi-tenancy
• PostgreSQL docs: Managing databases
• PostgreSQL docs: Database roles
• PostgreSQL docs: pg_dump