Architecture decisions, engineering write-ups, and PostgreSQL performance insights.
Your agent does not need your superuser connection string. PgBeam issues a scoped one, enforces read-only access, allowlists, PII masking, and budgets in the Postgres wire protocol, and records every statement. Any Postgres, no code changes.
Some agent actions are too consequential to autorun and too useful to forbid. Hold the write or the DDL in a queue, let a human approve it in the dashboard, and auto-approve the cases that are obviously safe.
An agent in a loop can hammer your database all night. A budget turns that into a bounded event. A kill-switch turns it off in one click. Together they cap the worst case before it becomes an incident.
An AI agent that reads a customer table does not need the raw email, phone number, or card. Column masking redacts, nulls, or hashes sensitive values in flight, so the model sees data it can still work with but never the real thing.
Table and column allowlists decide which columns a credential can touch. Row-level policies decide which rows. PgBeam appends a WHERE predicate to every query so the principal only ever sees the rows you allow.
You can give an agent a database connection string, or a hosted MCP endpoint. Both work. One of them gives the agent structured tools and a policy boundary instead of a raw socket.
Most agents only need to read. A read-only credential makes every INSERT, UPDATE, DELETE, and DDL impossible at the wire, which removes an entire class of agent failures before it can happen.
Claude Code, Cursor, LangChain, psql, a Python notebook: they all speak Postgres. A guarded PgBeam connection string drops into every one of them, with the policy attached and nothing to install.
An AI agent needs real database access to be useful and real guardrails to be safe. The PostgreSQL wire protocol is the one layer where you can enforce both, for any database, with zero code changes.
Most of PgBeam's 140,000-line codebase was written by AI agents. The setup that makes this work is simpler than you'd expect: a monorepo, a rules file, and a persistent knowledge base.
PgBeam's entire API surface is generated from a single OpenAPI spec: Go server types, route registration, TypeScript SDK, and interactive documentation. Here's how the pipeline works.
How PgBeam's query caching works: L1 process-local cache, optional L2 shared cache, stale-while-revalidate semantics, and cache key computation.
Vercel Functions can deploy to 20 regions. Most teams deploy to one, because their database is in us-east-1. The problem was never compute distribution. It was always the data layer.
The solutions for PostgreSQL latency across regions are either incomplete or locked to a specific platform. Here's why I built something different.