Authorization that lives in the database
Define row level security policies per table with a guided builder, so access rules survive whichever client connects.
- Per-table policies
- Guided builder
- Policies apply to every client
Rules the application cannot forget
A policy enforced by PostgreSQL applies to the Data API, a direct psql session and your application alike. There is no code path that quietly skips it.
Guided, not magic
The builder assembles USING and WITH CHECK expressions and shows you the SQL it will run. You keep the option to write the policy yourself.
Command-scoped
Separate policies for SELECT, INSERT, UPDATE and DELETE, because read access and write access are rarely the same question.
Enabled is a decision
Turning RLS on for a table denies everything until a policy allows it. That is the safe default, and the dashboard says so before you flip it.
Test policies with the role that will use them
A policy that looks right as a superuser can be wrong for the application role. Switch roles in the SQL editor and run the queries your application actually issues.
alter table documents enable row level security;
create policy documentsTenantRead
on documents for select
using (tenant_id = current_setting('app.tenant_id')::uuid);Build the whole backend in one project
One plan, one dashboard, one command line interface. PostgreSQL, applications, functions, storage and realtime.