Glossary
Multi-tenant
One application serving many customers (tenants), where data and permissions are isolated per organisation — not one database per customer from day one.
What does it mean?
In a multi-tenant system, customers typically share the same app and database, but each tenant only sees its own data. Isolation can use org_id in queries, RLS, separate schemas — or in extreme cases separate databases.
It is the architecture choice that often decides whether a SaaS product can scale sales without rewriting auth and the data model mid-growth.
When it is the right focus
You sell to companies, not only individuals
Organisations, roles, and invites show up quickly.
Multiple brands or white-label
Same platform, different customers who must not see each other.
You outgrow the one-account MVP
When the first enterprise customer asks for SSO and audit.
Billing per organisation
Stripe Customer + subscription belong to the tenant — not a random user.
Short answers
Is multi-tenant the same as multi-user?
No. Multi-user is several people. Multi-tenant is several isolated customers/organisations.
Do we need it in v1?
If you know you sell B2B with org accounts: yes, at least the org model. If you are B2C single users: wait.
Where does RLS fit?
RLS is a strong way to enforce tenant isolation in Postgres — see our RLS entry.
Read next
Read next
On tenant models, billing, and MVP scope.
- SaaS5 min read
Multi-tenant architecture: when, how — and what can wait
Multi-tenant sounds like something you must decide on day one. In practice it's a scale of choices — from "everyone in the same database with an org id" to full isolation. Here's how we choose without over-engineering the MVP.
→Multi-tenant architecture: when, how — and what can wait - SaaS5 min read
Stripe, billing, and org auth — what to have in place before your first paying customer
Billing and auth are the first place a SaaS product becomes expensive to fix afterwards. Here is how we think about Stripe, organisations, and self-service together — without reinventing what Stripe has already solved.
→Stripe, billing, and org auth — what to have in place before your first paying customer - SaaS3 min read
SaaS MVP: what belongs in v1 — and what waits
The hardest part of an MVP isn't building features — it's not building them. v1 should prove someone will use the product, not that you've built a mini enterprise platform.
→SaaS MVP: what belongs in v1 — and what waits
Outgrowing single-tenant?
Let’s design the tenant model you can own.
We cut scope to what you need now — and prepare what you know is coming.