multi-tenancy

Multi-tenancy

Tenant isolation is one rule — "you only touch what belongs to an organization you are in" — that must hold in every query, every server function and every screen. This skill is about writing that rule once and about the places it is forgotten.

Analogy: an office building with several companies. The lobby is shared, each floor is private. The security model isn't a guard on every desk — it's one badge system that every door consults. The failures are never the front doors; they are the service elevator, the cleaning contractor with a master key, and the show floor left open for visitors.

Discovery (max 3 questions, only if unknown)

1. Can one person ever belong to two organizations — a freelancer, an agency, a consultant, a founder with two companies?
2. Who creates an organization — anyone who signs up, or only you?
3. Is there a shared demo or sample account that strangers can enter?

Step 1 — Decide the membership model now

Model	Shape	Choose when
Single-org	users.org_id	The answer to question 1 is a certain, permanent no
Memberships	memberships(user_id, org_id, role) + an active-org selection	Any doubt at all

Default to memberships. The single-org shortcut saves a table today. Converting later, in one production app, meant touching 39 of 56 policies, 21 functions and 33 files — and exposed the side effects in Step 4.

Step 2 — One choke point

Every policy and query asks one function for the caller's tenant — current_org_id() — instead of reading a column directly.

• With memberships it returns the active organization, after checking the caller is really a member of it.
• Because everything goes through it, changing the model later changes one function.
• The role check lives beside it and filters by the caller's id. Never ask "is there an admin row?" — the first row returned belongs to someone.

Step 3 — "What I can see" is not "who is on the team"