pg_permissions

pg_permissions stores roles, sharing relationships and Cedar policies alongside your application data. Your backend can ask Postgres who can do what without calling a separate authorization service. If you want the database to enforce the same rules on a table, use row level security (RLS).

Check access from your backend

Can Alice read documents in Acme? With a server client, set the subject and ask for the permission in that organization. The quickstart walks through assigning the role and checking two users.

JavaScript

const { data: allowed, error } = await permissions
  .as({ id: 'alice' })
  .rbac.hasPermission({ permission: 'documents.read', scope: 'acme' })

if (error) throw error
if (!allowed) throw new Error('Forbidden')

SQL

begin;
select set_config('permissions.subject_id', 'alice', true);
select permissions.rbac_has_permission(
  permission => 'documents.read',
  scope => 'acme'
);
commit;

From the blog

pg_permissions: Authorization for Postgres

An authorization store and check engine for Postgres, with RBAC, OpenFGA and Cedar. Call it from your application, with optional Row Level Security integration.

Read the story →

Start with your access rules

Roles and permissionsGive users roles across your application or within each organization. Roles can inherit permissions.

Relationships and sharingShare individual objects, nest teams, and inherit access from folders with the OpenFGA model.

Policies with CedarWrite rules on users, resources and their attributes. Use explicit forbids to override Cedar permits.

Check access in your applicationCheck the signed-in user’s permission before serving a request.

Optional: enforce access with RLSApply your authorization rules to table reads and writes using Postgres policies.

Connect your applicationSet request identity, connect a JavaScript client, and separate client checks from admin operations.

Connect to Postgres

Install the extension in Postgres 16, 17 or 18, then connect your application. The overview explains why we built it and how each model fits into an application.

API reference

Look up a method in the JavaScript client reference, or browse the shared, RBAC, OpenFGA and Cedar APIs.

OpenFGA compatibility, Cedar compatibility, API limits, and CEL support describe the boundaries of the implementation. A check returns a decision for your backend to enforce. If you add RLS, standalone checks do not include any extra rules defined only in those table policies.

Design and evidence

The architecture guide explains how the three models share identity while keeping their rules separate. The Cedar design record describes how we compare decisions against Cedar’s own tests.

For latency and throughput measurements, see the benchmarks. Each workload includes the data size and test conditions.

For agents and other tools, the Markdown index links to plain-text versions of the documentation, including every language example.