rowstile: access rules in a policy file, enforced by Postgres

Authorization inside your Postgres. Sharing, groups, nested folders and tenants, written in one policy file and compiled to row-level security. There is no authorization service to run beside the database, and no permission data to copy into one and keep in step: the rules read the tables your app already has.

Write who-can-do-what in one small file, next to the data it depends on. The rowstile command compiles it into plain SQL: views, trigger-maintained tables for inheritance, row-level security policies, and functions for app code: checks, sharing, "who has access", "why", access requests, reviews, audit. Each change to the policy ships as a migration for the tool your app already uses (Alembic, Django, Prisma, Drizzle Kit, Rails, Laravel, Ecto, EF Core, sqlx, goose, dbmate, Flyway or plain SQL). Nothing is installed in the database first, and nothing has to run next to it: any Postgres 16, 17 or 18 works, managed or not, and the owner of your tables runs the migrations, no superuser needed.

app role app_user                               -- the Postgres role the app connects as
type user = app.users
type folder = app.folders
  owner  : user   = owner_id                    -- a relation read from a column
  parent : folder = parent_id
  editor : user   = app.folder_editors(folder_id -> user_id)   -- ... or from a link table
  can edit = owner or editor or parent.edit     -- inherited down the tree
  can view = edit
rules app.folders
  select                 : view
  update                 : edit
  update owner_id        : owner                -- only the owner gives it away
  update parent_id after : parent.edit          -- moved only under a folder they may edit

The app says who is asking in each transaction and queries its tables as usual; RLS filters every read and checks every write:

BEGIN;
SELECT authz.act_as('user', '42');         -- a trusted backend, or:
-- SELECT authz.login_key('ak_...');       -- an API key (optionally limited by scopes)
-- SELECT authz.login_jwt('eyJ...');       -- a JWT from your identity provider
SELECT * FROM app.folders;                             -- only the folders 42 may view
SELECT authz.can('folder', 7, 'edit');                 -- ask directly
SELECT * FROM authz.perms_of('folder', ARRAY['7', '8']);  -- a list's buttons, in one call
COMMIT;

Is it for you?

It fits when:

• your app's data is in one Postgres database;
• who may see or change a row depends on other rows: its owner, the members of a team (teams inside teams), a folder or a project that passes access down, a tenant, what people share with each other;
• you were about to add an authorization service and keep it in step with the database, or your hand-written row-level security has become hard to test and to change.

It doesn't when:

• what decides access is in several databases, or outside Postgres;
• a browser reads the tables through Supabase's Data API (its roles are not the app role: a backend has to sign in);
• one tree takes many moves and links a second (they wait for each other);
• you need an outside audit or a vendor behind it today: rowstile is in beta, with one maintainer.

Status

rowstile 0.1.0 is in beta: complete enough to use before it is released, and it may still change where using it shows a need. Until 1.0, a minor release may change the language, the authz.* functions, the SDKs and the file formats; from the beta on, each release upgrades a database from the one before it, and the changelog says what to do. What a 0.x release promises.

rowstile was called rowfence until 0.1.0-alpha.1; another product had the name first. The changelog says what the alphas were: [Before the beta](CHANGELOG.md#b

... View full README on GitHub