Tenancy
Row-level security (RLS)
A database feature that filters which rows a query can see or change according to a policy the database enforces.
What Row-level security (RLS) means
Row-level security is a database feature — in PostgreSQL, CREATE POLICY with ENABLE ROW LEVEL SECURITY — that restricts which rows each query can read or write according to a policy evaluated by the database itself. In multi-tenant systems it is used so a query missing its tenant filter returns only the current tenant's rows instead of everyone's.
Defined in: PostgreSQL documentation, Row Security Policies (ddl-rowsecurity).
How it works
A policy is a boolean expression attached to a table, for example tenant_id = current_setting('app.tenant_id'). The application sets that value from the authenticated context at the start of each transaction, and the database applies the policy to every query on the table.
PostgreSQL exempts table owners and roles with BYPASSRLS from policies unless FORCE ROW LEVEL SECURITY is set. The application must therefore connect as a role that neither owns the tables nor bypasses RLS.
The mistake people actually make
Setting the tenant variable at session level on a pooled connection. The next request served by that connection inherits the previous tenant's context. Scope it to the transaction.
In Authreads
How this applies here
Tenant isolation in Authreads is enforced at the data layer rather than only in application code.
Every capability is listed on /roadmap as Available, In progress or Planned. Nothing is described as available here that is not listed as Available there.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.