Can't I just give the reference MCP server a read-only connection string?

You can, and you should if you self-host. That blocks writes, but it still has no column masking, query budgets, per-agent audit, OAuth, or a kill-switch. PgBeam enforces read-only plus all of that on the wire, and revokes instantly.

Do I have to host anything with PgBeam?

No. The MCP endpoint is hosted. You connect your database, issue an agent credential, and paste the URL and bearer token into your MCP client. There is no server process to run or patch.

Is it the same tools as the reference server?

PgBeam exposes query, list_tables, describe_table, and explain, each enforced against the credential's policy. The difference is not the tool list, it is that the limits are enforced for you rather than left to your code.

Comparison

PgBeam vs a DIY Postgres MCP server

The reference Postgres MCP server runs on whatever your connection string grants, usually full privileges, and the guardrails are whatever you code and maintain. PgBeam is a hosted, policy-enforced MCP endpoint with read-only, masking, budgets, and audit built in.

Get Started Read the docs

a DIY Postgres MCP server: A DIY Postgres MCP server is a self-hosted MCP process (often the reference server) that you point at a Postgres connection string so an agent can run SQL through MCP tools.

Running the reference Postgres MCP server is the fastest way to give an agent SQL tools, and for a local toy database it is fine. In production the problem is the connection string: the server can do whatever that string grants, which is usually everything, and any limit beyond that is code you write and then maintain forever. PgBeam is the same MCP surface, hosted, with the policy already enforced on the wire.

PgBeam vs a DIY Postgres MCP server, side by side

Capability	PgBeam	a DIY Postgres MCP server
Read-only enforcement	Built in, at the wire	Whatever the DSN grants
Table / column allowlists	Per credential	DIY
PII masking	Yes	DIY
Query budgets / max rows	Yes	DIY
Per-statement audit trail	Yes	DIY
Instant revoke / kill-switch	Yes	DIY
OAuth-protected endpoint	Yes	DIY
Hosting + patching	Managed	You run it
Also a guarded connection string	Yes (same policy)	No

The connection string is the problem

A DIY MCP server is only as constrained as the credential you hand it. Point it at your app's connection string and the agent inherits full privileges; the only guardrails are the ones you coded into the server, and they are now yours to maintain, test, and keep current as the schema changes.

PgBeam issues a scoped agent credential and enforces the policy in the Postgres wire protocol, not in the MCP layer. Read-only, allowlists, masking, budgets, and the kill-switch apply to every tool call, and a blocked call returns an LLM-readable reason the agent can act on.

Hosted, with one policy for both front doors

There is no server process to deploy, patch, or scale. The endpoint exposes query, list_tables, describe_table, and explain, runs on a globally distributed proxy near your database, and is OAuth-protected so MCP clients can discover and connect to it.

The same policy engine also backs a guarded connection string, so an agent that speaks raw SQL and one that speaks MCP are governed by the exact same rules. With a DIY server you would build and maintain that twice.

When a DIY Postgres MCP server is the better fit

The reference MCP server is open source, free, and runs locally in minutes, which is perfect for a throwaway or local database where you control the blast radius. If you want full control of the code and have no need for hosted policy, masking, audit, or OAuth, self-hosting is a fine choice. PgBeam is for production agent access where the guardrails have to be enforced, not coded.

More comparisons

PgBeam vs AWS RDS Proxy PgBeam vs PgBouncer PgBeam vs Supavisor PgBeam vs Neon PgBeam vs a read-only Postgres role

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