Comparison
PgBeam vs a read-only Postgres role
A read-only role blocks writes and nothing else. PgBeam enforces read-only per credential at the wire and adds allowlists, PII masking, query budgets, a kill-switch, and a per-statement audit trail, without touching your database roles.
a read-only Postgres role: A read-only Postgres role is a database role with SELECT granted and writes withheld, created with GRANT inside the database.
A read-only role is the first thing most teams reach for when an agent needs database access, and for blocking writes it works. The gap shows up the moment you need anything more than read-only: a role cannot mask a column, cap query volume, audit per agent, or be revoked without a rotation. PgBeam enforces read-only at the wire and layers the rest on top, per credential, without changing your roles.
PgBeam vs a read-only Postgres role, side by side
| Capability | PgBeam | a read-only Postgres role |
|---|---|---|
| Block writes and DDL | Yes, at the wire | Yes (GRANT) |
| Table / column allowlists | Per credential | Coarse (GRANT per object) |
| Row-level WHERE filter per agent | Yes | RLS, hand-written policies |
| PII masking (redact / null / hash) | Yes | No |
| Query budgets / max rows | Yes | No |
| Per-statement audit trail | Yes | log_statement only |
| Instant revoke / kill-switch | Yes, per credential | Rotate the role |
| Hosted MCP endpoint | Yes | No |
| Works without touching DB roles | Yes | Lives in the database |
Read-only is the floor, not the policy
A read-only role enforces exactly one rule: no writes. It gives you no column masking, no per-query budget, no max-rows ceiling, and no per-agent audit beyond what log_statement records into the database log. For a single trusted reader that is fine. For an autonomous agent that can be prompt-injected, it leaves most of the blast radius open.
PgBeam enforces read-only at the wire and adds the rest as policy on the same credential: table and column allowlists, a row-level WHERE filter, PII masking, query-count budgets, max rows, and statement timeouts. An UPDATE or DELETE without a WHERE clause is blocked outright for agent credentials even where writes are allowed.
Revoke without a rotation
Revoking a read-only role means rotating it and updating every consumer that used it, which is slow enough that it rarely happens mid-incident. A PgBeam credential is revoked with one click, and a per-credential or project-wide kill-switch refuses the next statement immediately, with no change inside the database.
Because PgBeam lives in the wire protocol, none of this touches your database roles or requires a migration. The same policy works on RDS, Aurora, self-hosted, or any managed Postgres, and every decision is recorded in an exportable audit trail.
When a read-only Postgres role is the better fit
A read-only role is free, native, and needs no extra hop. If a single trusted, non-agent reader needs SELECT on a few tables and you never need masking, budgets, per-agent audit, or instant revoke, a role is the simplest possible answer. PgBeam is for when an agent is the reader and read-only alone is not enough.
Questions
Safe Postgres access for your agents
Start with a 14-day free trial. No credit card required.
Technical preview. For internal testing only.
Get Started