Back to insights

Engineering Practice5 min read

Your data, kept apart

Multi-tenancy is not a feature you can add later. It is a property of the database, and either it is true where the query runs or it is not true at all.

The first question a careful buyer asks about shared software is some version of: who else can see my stuff? The honest answer is decided long before anyone writes a settings page. It is decided by where in the system the promise of separation lives. We run our own business on the marketing and operations platform we built, alongside the tenants who use it. That is the most demanding arrangement we could choose: we are the co-tenant whose data has to stay put like everyone else's. Here is what running that has taught us. Separation enforced by discipline is not separation. If every query has to remember to filter by workspace — if correctness depends on each developer being careful, every time, forever — then the system's isolation is a hope, not a property. People get tired, code gets copied at midnight, and a missing clause in one query is a leak. The only separation worth trusting is the kind the database itself refuses to break. In our platform, every query runs through a scoped client, and row-level security enforces the tenant boundary underneath it. A query that forgets its place does not return a neighbour's rows. It returns nothing, loudly. The same shape shows up in our fleet compliance product, where each carrier's safety records live behind the same wall. A compliance officer's trust is not won on the marketing page; it is won when they ask "how do I know another fleet can't see our audits?" and the answer is a mechanism, not a promise. Two corollaries follow. First, the audit trail matters as much as the wall. Isolation says who could not see your data; the audit says who did see it, and what they changed. Operators that change records leave a trail, and that trail is what makes the system usable by real organisations, where "who approved this?" is a weekly question. Second, test the wall like an attacker. Our tests include the queries a tired developer would write — the ones missing their scope — and they assert failure. A security property that is never exercised negatively is a slogan. If you are buying shared software, ask the vendor where isolation lives. "Our team is careful" is not an answer. "The database enforces it, and we test that it does" is. If you are building shared software, put the boundary where no individual query can route around it, on day one. Retrofitting separation onto a live multi-tenant system is the most expensive migration there is — more expensive than the one you were trying to avoid.

Subscribe

Get the next one in your inbox.

Only when there is something worth reading. Nothing else.

Keep reading

More writing.

All insights

Want to talk about this?

Bring it to the people who built it.

If anything in this piece touches a system you are trying to ship, we would like to hear about it.