Multi-Tenant Data Isolation: Why "We Filter By Account" Isn't Enough
If you manage properties for more than one owner, or across more than one legal entity, there's a question worth asking about any software you put that data into: what actually stops Owner A's financials from showing up somewhere Owner B's team can see them? "We filter by account in the UI" and "it's not possible to query across accounts" are very different answers — and the difference matters most exactly when something goes wrong, not when everything works as intended.
Application-level filtering is a convention, not a guarantee
Most software isolates tenant data by adding a filter to every query — "only rows where company_id matches." That works, right up until one query somewhere in the codebase forgets the filter: a new endpoint, a reporting query written in a hurry, a background job that loops over "all" records instead of one company's. Nothing enforces the rule except every developer remembering it, every time, forever. For a single-tenant app that's a minor risk. For software holding multiple property owners' financial and tenant data, it's a different category of problem.
What database-level isolation actually means
The alternative is enforcing the boundary in the database itself — Postgres row-level security, in Casement's case — so that even a query that forgets to filter by company simply can't see another company's rows. It's not a UI restriction layered on top of a shared view of the data; the database itself refuses to return it. That's a meaningfully stronger guarantee than "the application is supposed to filter this," because it doesn't depend on every line of application code getting it right.
Why this matters specifically for property managers
- You're not the only owner of the data. Unlike a typical single-company SaaS user, a property manager acting for multiple owners is handling other people's financial and tenant information as a matter of course — the stakes of a leak are someone else's, not just your own.
- Owners ask. A landlord client evaluating whether to trust a property manager with their portfolio's data is entitled to ask how it's isolated from everyone else's — "enforced at the database level" is a concrete answer; "we're careful" is not.
How Casement handles this
Every tenant table in Casement carries a company identifier enforced by Postgres row-level security, not just application-level filtering — and the application layer still filters explicitly on top of that, as a second check rather than the only one. It's not the most visible feature in a product demo, but it's the one underneath every other one.
Casement is currently onboarding a small number of pilot property management companies. If you manage for more than one owner, this is worth asking about directly in a live demo.