Database users and access.

Database users.

A database user is a principal that connects to the database and runs queries. Open Security → Database users. The table lists every user with its authentication kind, the roles attached to it, how many API keys it holds, and when it was created. A disabled user is flagged inline.

Create a user.

+ Create user opens a dialog with exactly three inputs. There is no read-only switch here — what a user can do comes from the roles you attach and the grants those roles hold, which you set on Database RBAC.

• Username — free text, e.g. analyst_ro.
• Auth — API key or Password (SCRAM). Picking Password reveals a password field beside the dropdown.
• Roles — comma-separated role names that already exist on the database.

An API-key user's key is returned once, in the dialog, under a API KEY — COPY NOW, SHOWN ONCE banner. Copy it before you close the dialog; the console cannot show it again, because only a hash is stored.

Rotating and removing.

Each row carries two actions. + key issues an additional API key for that user and shows it once, in a browser prompt — useful for handing a second consumer its own credential, or for rolling one over before you retire the old one. delete asks for confirmation and then removes the user outright.

There is no session list in the console, and nothing to "sign out". Deleting a user removes it from the database's authorization store, so the next request that identifies as that user is rejected as unauthorized rather than served. In-flight requests already executing are not interrupted.

API keys and access tokens.

The console issues three different credentials, from three different places. They are not interchangeable, and mixing them up is the usual cause of a confusing 401.

Personal access tokens.

Security → Access tokens lists one card per database, and inside it your own tokens for that database. Give a token a name, optionally tick read-only, and press Create token. Existing tokens can be rotated or revoked one at a time, and each row shows a truncated prefix plus a READ/WRITE or READ-ONLY badge.

A token's access level is derived from your org role rather than chosen freely: owner, admin and cluster operator mint read/write tokens; every other role, including custom ones, mints read-only. Ticking read-only steps down from that ceiling but never up. The database enforces the restriction: a read-only token is refused on write requests. The level is also re-derived from your current role whenever that database's token set is rebuilt, so a demotion narrows the tokens you already hold.

If a credential leaks.

• A personal token — revoke it on Access tokens. Only that token stops working; deployed clients using the shared bearer are untouched.
• The shared bearer — rotate it on API keys, then redeploy every client that carries it. This one is disruptive by design: the old value stops working immediately.
• A database-user key — on Database users, delete the user (removing all its keys) or issue a fresh key with + key and move consumers over.
• Then tighten the blast radius: put the source addresses on the IP access list below, and check Cluster audit for authorization changes you did not make.

Network access.

Credentials decide who; the IP access list decides from where. Open your database from Databases and pick the Network access tab.

The default is an empty list, which allows any address. Add a single entry and the rule flips: only the listed ranges can connect, over both HTTPS and the Postgres wire protocol. The status line above the editor spells out which state you are in.

1. 1. Type an address or range into IP address. A bare IPv4 address is stored as a single host (/32); a bare IPv6 address becomes a /128. Explicit CIDR ranges are accepted as typed.
2. 2. Add an optional Description so the entry still means something in six months, then press Add entry.
3. 3. The shortcuts do the obvious things: + Add my current IP address fills in the address you're browsing from, and + Allow access from anywhere appends 0.0.0.0/0.
4. 4. Press Save changes to apply, or Discard to drop the staged edits. The console says changes take effect within a few seconds.

On a dedicated database the tab carries two more sub-tabs, Peering and Private Endpoint. Both are request forms rather than self-serve toggles: you submit your network details and our team completes the connection and sends back the acceptance details. A free database has neither — the IP access list is its only network control, and the console hides the other two entirely.

Row-level security.

Security → Row-level security attaches a USING predicate to a (table, role) pair. When a query reads that table as a user holding that role, rows that fail the predicate are dropped from the result. With no policies on a table, every role reads every row.

The predicate language the console documents on the page itself is: =, !=, < <= > >=, IN (…), IS [NOT] NULL, AND / OR / NOT, and CURRENT_USER, which resolves to the acting database user's name.

+ Policy asks for a table, a role and the predicate; all three are required. The CMD column shows which command the policy covers — policies created from this page cover reads. The effective-policy tester takes a database user and a table and reports one of three verdicts: superuser — sees all, restricted, or unrestricted, listing the policies that apply.

Cluster audit.

Security → Cluster audit is the append-only, hash-chained record of authorization changes on the database. Each entry carries the previous entry's hash, so altering or deleting anything in the past invalidates every hash after it.

Every row is one authorization change. The actions you will see are user.create, user.delete, user.rotate_key, role.create, role.delete, grant.put, grant.revoke, rls.put and rls.delete. The target names what changed — a username, or role@object for a grant or policy — and detail holds the change itself as JSON. Hover a truncated hash or detail cell to see it in full.

Verify chain recomputes every link and reports either chain intact or a tamper verdict naming the first broken sequence number. Export NDJSON downloads the whole chain, one JSON object per line, for a SIEM or log pipeline.

This log covers the database's authorization surface only. Account-level activity — members joining, databases being created, billing changes — lives in the separate org Audit log at the bottom of the Security group.

What's enforced, and what isn't.

Access-control screens are easy to over-read, so here is the honest boundary of the database layer as the console ships it today. Treat everything not on the enforced list as a record of intent — useful for review and audit, not as a barrier.

If you need a guarantee stronger than the row above, say so before you design around it — write us at support@originchain.ai.