How stores are kept apart

CIQRA is multi-tenant: many stores share the same platform. The question that follows is the

only one that matters — what stops one store from reading another’s data?

Enforced in the database, not only in the code

Isolation is enforced with PostgreSQL row-level security (RLS). Protected tables carry a policy that constrains rows to the store that owns them, and it is the database that applies it.

The distinction is the whole point. Isolation implemented only in application code holds until one query is written without its filter. RLS puts the rule underneath the query, so a forgotten filter returns nothing rather than someone else’s rows.

The measured coverage

Measurement	Value
Tables carrying row-level security	224 of 269
Policies in force	226

These numbers come from a guard that reads the live schema, not from a checklist. That distinction matters more than the numbers themselves: a checklist records what someone intended to protect and drifts silently the moment a table is added, while a guard counts what is actually protected and fails when the count is wrong.

The tables that are not covered

45 of the 269 do not carry a policy, and we would rather name that than average it away. They are platform-level tables that are not store-scoped in the first place — a store owns no rows in them, so there is nothing to partition.

Any table that is store-scoped and lacks a policy would be a defect, and is treated as one. The guard exists to make that visible rather than to produce a comfortable percentage.

What this page does not say

• It does not claim that isolation has been verified by an external party. No third-party penetration test has been performed — see Transparency.
• It does not describe access controls for CIQRA’s own staff. That is a different question from tenant isolation, and it has not been measured for publication here.