DRAFTThis page is not published. Only visible in development mode.

Policies

Policies are row-level security declared in the database. Because frontends query ReifyDB directly, there is no backend API layer to enforce access rules - policies are that layer. Non-root identities are denied by default; a policy grants access and shapes what each operation may see and do. Root bypasses policies entirely.

Read policies: filter and mask

A policy attaches to an object and defines a pipeline per operation. The from pipeline runs on reads - a filter restricts which rows non-root identities can see at all. Run the snippets on this page in order:

A map in the from pipeline reshapes what readers get: mask a column by overwriting it, or hide it by omitting it from the projection:

Write policies: require

The insert, update, and delete operations take a require pipeline - a predicate every affected row must satisfy, or the mutation is rejected:

For a non-root identity, a violating write fails with a policy error and the transaction does not commit:

text

> insert dm_pol::documents [{ id: 3, title: "Comp review", public: false }]

Error POLICY_001
  Policy 'no_private_inserts' denied insert on dm_pol::documents

HELP
  The write operation violates a policy constraint

Policies attach to more than tables

The same mechanism covers every primitive an identity can touch. Each target has its own statement form and its own set of valid operations:

--create table policy, create view policy, create series policy, create ringbuffer policy, create dictionary policy - data shapes, with from / insert / update / delete operations
--create namespace policy ... on ns - one rule for everything inside a namespace
--create procedure policy - who may call a routine
--create session policy - which session kinds (query, command, subscription) an identity may open

Policy predicates can reference the caller: tenant isolation is one policy comparing a row column to the requesting identity, for example filter { org_id == $identity.org_id }.

Lifecycle and inspection

Policies are catalog objects: list them through the system catalog, disable and re-enable them without losing their definition, and drop them when obsolete.

Disabling a policy does not open access up - with no active policy, non-root identities fall back to default deny.

These snippets run as root

The in-browser playground executes as root, which policies never restrict - so you can create, inspect, and drop policies here, but you will not see enforcement. Enforcement applies to non-root identities connecting through client sessions, as in the static example above.