How QuantX Ops Keeps One Company's Data Away From Another's
Multi-tenancy done at the database level: row-level security, and foreign keys that make a reference across a tenant boundary impossible to write rather than merely unlikely.
Every SaaS vendor says your data is isolated. The question worth asking is what enforces it — because "our code is careful" is a promise, and a promise is only as good as the next person to touch the code.
Row-level security, in the database
QuantX Ops's isolation is enforced by PostgreSQL, not by application code. Every tenant-scoped table carries a row-level security policy filtering on the tenant of the connection making the query. A query that forgets to filter still cannot see another company's rows, because the database applies the filter whether the code asked for it or not.
And references cannot cross
Row-level security filters what a query reads. A foreign key checks that a referenced row exists. Neither of them, on its own, checks that two rows agree about whose data they are — so a record pointing across a tenant boundary is possible in most systems built this way.
QuantX Ops closes that with composite foreign keys: every reference is on
(tenant_id, id) rather than on id alone. A reference that crosses a
tenant boundary is not wrong-but-tolerated; it cannot be written at all. All 313 such
relationships in the schema are built this way, and an integrity sweep re-checks them.
What that means for you
- Your data cannot appear in another customer's report through a coding mistake.
- A bug in one module cannot leak across tenants, because the boundary is not the module's to enforce.
- The guarantee is testable, not asserted — and it is tested.
Access within your company is separate, and granular: duty roles and permission keys decide who sees salaries, who can issue an invoice, and who can approve what.