I've been shipping 'multi-tenant' wrong for a decade
The author reflects on a decade of misunderstanding multi-tenancy in application development. They highlight the shift from enforcing tenant awareness through code to implementing Row-Level Security in the database. This change significantly reduces the risk of cross-tenant data leaks by ensuring that the database itself manages tenant isolation.
- ▪The author has been developing multi-tenant applications since 2014 but realized they were only implementing tenant awareness, not true multi-tenancy.
- ▪The introduction of Row-Level Security in PostgreSQL allows for better tenant isolation by enforcing policies directly in the database.
- ▪By moving tenant checks into the database, the application only needs to set a session variable, reducing the chances of errors.
Opening excerpt (first ~120 words) tap to expand
I've Been Shipping 'Multi-Tenant' Wrong for a Decade May 13, 2026 I’ve been writing “multi-tenant” applications since around 2014. Each time, I told myself this one would be done properly. Each time, “properly” meant a tenant_id column on every table, a base repository that injected WHERE tenant_id = $1, and a strongly worded paragraph in the onboarding doc. That is not multi-tenancy. That is tenant awareness, enforced by discipline and code review. This is the first project where I think I’ve actually done it right. The thing that changed is not my discipline. It is where the contract lives. What I used to call multi-tenant The pattern I shipped, over and over: A tenant_id column on every business table. A base repository or ORM scope that automatically adds WHERE tenant_id = :current.
…
Excerpt limited to ~120 words for fair-use compliance. The full article is at Adriacidre.
Discussion
0 commentsMore from Adriacidre
