Glossary
RLS — Row Level Security
A database policy that ensures each query only sees the rows it is allowed to — typically scoped to an organisation or user.
What does it mean?
RLS (Row Level Security) is a Postgres feature that filters rows automatically based on policies you define. The application does not have to remember `WHERE org_id = …` in every query — the database enforces it.
In multi-tenant SaaS, RLS is often the last line of defence: even if a bug forgets a filter in code, customer A’s data does not leak to customer B.
When it matters
Multi-tenant products
When many organisations share one database and isolation must not be optional.
Customer portals
When external users see orders, documents, or tickets — and mistakes are expensive.
Compliance and due diligence
When you must explain how data is isolated — not only trust application code.
A growing engineering team
When more developers touch queries and manual WHERE filters become a risk.
Short answers
Is RLS the same as roles in the app?
No. App roles control what the UI allows. RLS controls what the database returns at all — even if the code fails.
Can we start without RLS?
For an early prototype with few users: sometimes. Before paying customers with sensitive data: no — it is more expensive to cut in later.
Does it only work in Postgres?
RLS as a concept is strongest in Postgres. Other databases have similar patterns, but we typically build on Postgres + RLS.
Read next
Read next
Deeper guides on multi-tenant and portals.
- 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 - Web6 min read
When do you need a customer portal — and when is a tool enough?
Most B2B companies end up building something that looks like a customer portal. The question is whether you should build it, or whether a standard tool already does the job. Here's the framework we use.
→When do you need a customer portal — and when is a tool enough? - 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
Need data isolation done right?
Let’s review your tenant model.
We look at queries, policies, and risks — without selling unnecessary complexity.