Row-Level Security and the Tenant Key: The Retrofit That Costs Most

Adding a tenant key to a system that already has a live customer means touching every table, every query and every access policy at once. On a system we measured, the organisation key appears in 66 of 97 migrations. Doing that work before the second customer is cheap. Doing it after is the most expensive change on this road.

By Imtiaz Hasan · Updated September 2026 · Digital Workforce System

What the tenant key actually is

An internal system does not need to know whose data it is looking at, because all of it belongs to one company. A platform does. The tenant key is the column that answers that question, and everything else about isolation depends on it existing.

The usual shape is an organisation_id on every table that holds customer data, plus a policy on each table that filters by the organisations the current user belongs to.

What it looks like when it was done early

We measured a production system built for a single operator — one customer, no plans for a second at the time it was written:

The policies scope by membership, not by a hard-coded customer. That one decision is why the system can run as one database holding a single organisation, or one holding several, with no change to the schema.

Why the retrofit is the expensive one

Adding a tenant key later is not a single change. It is four, and they arrive together:

• A column on every table that holds customer data, and a decision about which tables those are.
• A backfill for every existing row, which means downtime or a careful online migration against live data.
• A policy on every table, plus the function the policies call, plus a test that the policies actually deny what they should.
• A review of every query that reads those tables. This is the part people underestimate. An unscoped read that was correct when there was one customer becomes a data leak the moment there are two.

Why put it in the database rather than the code

Application-level filtering works until somebody writes a query that forgets. Row-level security moves the rule to where the data is, so a forgotten filter returns nothing rather than everything.

That matters most in the places nobody reviews: an export, a reporting endpoint, a background job written at speed, an admin screen someone built for themselves. Those are where the leaks happen, and they are exactly the code paths that skip a code review.

What to do now, at one customer

1. Put the key on every table that holds customer data. One organisation row, all your data pointing at it. It costs almost nothing today.
2. Scope policies by membership rather than by a fixed identifier, so the same policy works whether there is one organisation or forty.
3. Write one denial test. Create a second organisation in a test environment and confirm it can see nothing. Passing this once is worth more than the policies looking correct.
4. Then stop. You do not need multi-tenant infrastructure, an onboarding flow or a billing system. You need the key and the policies, which are the parts that get more expensive with every month you wait.

When you can skip this

If the system will only ever serve your own company, none of this earns its keep. The work is insurance against a second customer, and if there will never be one you are paying a premium for nothing. The honest test is whether anyone outside has asked — not whether you hope they will.