Your Data Is in a Database With Ten Thousand Strangers

Software sold as a monthly subscription is almost always multi-tenant. One running copy of the application serves every customer, and one database holds everybody's data. Each row carries a column saying which account it belongs to, and the application's job is to never forget to filter on it.

That design is not laziness — it is what makes the price possible. Running one system for ten thousand customers is enormously cheaper than running ten thousand systems, and every efficiency of that model gets passed along in the subscription fee. When software costs a few tens of dollars a month, this is the reason.

The consequence is that isolation becomes a property of correctness rather than a property of structure. Nothing physical is separating tenants. The separation is a rule the code applies, and rules that have to be applied consistently across thousands of code paths, for years, by rotating teams, are exactly the kind of rule that eventually is not applied somewhere.

Good multi-tenant products do not rely on developers remembering. They use row-level security, which moves the tenant filter out of application code and into the database itself. The database is told that this table may only ever return rows matching the current account, and it enforces that regardless of what the application asks for. A query that forgets its filter returns nothing instead of returning everything.

This is a genuine improvement and it deserves credit. It converts a mistake that leaks data into a mistake that shows an empty screen, which is the right direction for a failure to fall. Any serious multi-tenant vendor uses it, and we use it ourselves where a system is legitimately shared.

The word carrying the weight is mostly. The policy has to be enabled on every table, including the one added last week. It has to be written correctly, and a policy with a subtly wrong condition enforces the wrong thing confidently. It has to survive privileged connections — background jobs, admin tooling, reporting pipelines and data exports frequently run with credentials that bypass it, because they legitimately need to see across accounts. Each of those is a normal engineering necessity, and each is a path around the control.

On an ordinary day these two architectures are indistinguishable to the person using them. The screens look the same. The data loads. Nobody thinks about tables.

The difference is entirely about what happens when something goes wrong, and it shows up as three questions you will suddenly care about very much. Whose data was exposed — just yours, or everyone's? Can anyone tell you — is there a log that distinguishes your records from the rest, or does the honest answer become "we cannot rule it out"? And can you do anything about it — can you rotate your own credentials, pull your own export, and shut your own instance down, or do you wait for a vendor's status page?

In a shared system the answers are largely out of your hands, which is why breach notifications from subscription software read the way they do. They arrive as email, they are vague about scope, and there is nothing for the customer to do but wait. That is not evasiveness. It is a structural consequence: when a boundary is logical rather than physical, establishing exactly what was on the wrong side of it after the fact is genuinely hard.

Every Araptus Doon deployment is its own application with its own database and its own credentials. There is no shared table, no tenant column, and no query anybody could write — correctly or otherwise — that returns another business's records, because those records are not in the same system to be returned.

That does not make it invulnerable, and the same honesty applies here as anywhere: an isolated system can still be misconfigured, its credentials can still be mishandled, and the people with access are still the largest risk in any architecture. What isolation changes is the shape of the worst case. A mistake reaches one business. The logs describe one business. The keys belong to one business, and rotating them is a decision that business gets to make.

It also changes what leaving looks like. When your data is genuinely separate, an export is a copy of your system rather than a filtered extract from someone else's — which is the difference between switching vendors and negotiating with one. That is a security property and a commercial one at the same time, and it is the reason isolation sits under everything we build.