Engineering
Tenant isolation without the performance tax
The worst multi-tenant bug is the one where org A sees a sliver of org B. We designed the data path so that failure is structurally impossible, not merely unlikely.
9 min read
In a multi-tenant system, the single most important invariant is that one organization can never read another's data. It sounds obvious, and it is violated constantly — usually by a query that forgot its tenant filter, returning rows it should never have touched.
Authorize, then query
The fragile pattern is to fetch broadly and filter for the current tenant in application code. One missing WHERE clause and the isolation is gone. Sillops inverts the order: a request is scoped to its organization before any data is read, and the tenant boundary is enforced at the data layer, not remembered by hand in every handler.
Because the scope is established once, up front, there is no per-query discipline to forget. A developer writing a new endpoint cannot accidentally widen it past the tenant, because the widening was never available to them.
The performance question
Isolation is often sold as a cost — separate databases per tenant, or heavy row-level policies that fight the query planner. We get most of the safety with an indexed tenant scope that the planner treats as a first-class filter, so the isolating condition is also the condition that makes the query fast. Safety and speed pull in the same direction instead of against each other.