Alex Shapalov ships a roughly 6 MB read-only Postgres diagnostic tool

Alexandr "Alex" Shapalov released Pgbot in August 2026, a roughly 5.9 MB read-only Go binary that turns PostgreSQL statistics into deterministic findings for developers and AI agents via CLI, JSON output, and Model Context Protocol tools. The tool enforces read-only access at the database layer, requiring a dedicated login with the pg_monitor role and no write grants, to safely give AI agents visibility without operational authority.

Alex Shapalov ships a roughly 6 MB read-only Postgres diagnostic tool The Go binary turns PostgreSQL statistics into deterministic findings for developers and AI agents through a CLI, JSON output and Model Context Protocol tools. By RuntimeWire Staff /author/runtimewire-staff · Published Primary source: Pgbot https://pgbot.dev/ Why it matters AI agents are gaining access to production infrastructure faster than most teams are defining safe boundaries. Pgbot gives them structured PostgreSQL evidence while enforcing read-only access at the database layer, a practical model for agent tools that need visibility without operational authority. Alexandr "Alex" Shapalov @alxshp https://x.com/alxshp?ref=runtimewire released Pgbot https://pgbot.dev/?ref=runtimewire in August 2026, giving developers and AI agents a small, read-only tool for finding problems inside a running PostgreSQL database without installing a monitoring stack. Shapalov describes himself as a developer building infrastructure for developers and agents. His personal site https://alex.shapalov.com/?ref=runtimewire traces his roots to Lviv, Ukraine, while his LinkedIn profile https://www.linkedin.com/in/shapalov?ref=runtimewire places him in Los Angeles and lists more than a decade of Ruby on Rails experience. Pgbot applies that application developer's perspective to database operations: connect one binary, collect the signals PostgreSQL already exposes, and put the most urgent findings first. Pgbot gives a model a structured view of connections, locks, transactions, replication, write-ahead logs, cache performance, slow queries, table growth, indexes and vacuum activity while withholding permission to repair a production database. The agent can interpret those findings, while the tool retains control over how they are collected. That division of labor is the product's central decision. Pgbot computes its findings deterministically in Go. Its optional AI layer explains and prioritizes those findings, rather than generating the underlying diagnosis from scratch. A production tool with the write button removed Pgbot's repository https://github.com/pgrundev/pgbot?ref=runtimewire recommends a dedicated PostgreSQL login holding the pg monitor role and no write grants. Each session is pinned to read-only mode, with statement and lock timeouts. Individual probes run inside read-only transactions. Those controls matter because an agent can misunderstand an instruction, choose an unsafe query or act on an incomplete picture. Pgbot limits the consequences at the database permission layer. The model does not get to decide whether it should behave safely. The core inspect command produces a graded health report, grouping findings by severity and listing healthy subsystems alongside failures. Focused commands examine queries, indexes, tables and vacuum behavior. Pgbot can also compare locally stored baselines, identify regressions and emit machine-readable JSON for scripts, CI pipelines and agents. Pgbot's Model Context Protocol mode exposes deterministic, read-only inspection functions to clients such as Claude Code and Cursor. The repository documentation https://github.com/pgrundev/pgbot?ref=runtimewire lists tools for database inspection, unused-index analysis, top-query reporting and vacuum health, along with a diagnostic prompt and a baselines resource. The safety boundary comes with a practical caveat. Pgbot's deterministic inspection commands stay local, while its optional explanation commands send findings context to a configured model endpoint. Operators deciding where Pgbot fits in a production environment still need to distinguish local collection from model-assisted explanation. A small binary with room to grow Pgbot's v0.3.0 release https://github.com/pgrundev/pgbot/releases/tag/v0.3.0?ref=runtimewire was dated August 18, 2026, according to repository-tracking data. The project promotes a roughly 5.9 MB static binary that connects directly to an existing database and produces a findings-first health report. The project's verified capabilities include local baseline comparisons, deterministic causal analysis and structured JSON output. That is a wider remit than a one-command health check, while the local design keeps the operating model relatively simple. That expansion creates a product tension Shapalov will have to manage. Pgbot earns attention through its small footprint and narrow safety model. Every added diagnostic, model integration and configuration surface makes the tool more useful, while also moving it closer to the operational complexity it was built to avoid. Agents need eyes before they need hands Pgbot is arriving as database vendors and observability providers add ways to make PostgreSQL accessible to coding agents. Pganalyze opened its MCP server to public preview in May 2026 https://pganalyze.com/blog/mcp-server-public-preview?ref=runtimewire , using statistics already collected by its monitoring service so models do not connect directly to production databases. Neon's Codex plugin https://neon.com/blog/neon-codex-plugin?ref=runtimewire , released on April 16, lets agents provision and manage databases through Neon's MCP integration. Database branching products such as Ardent https://www.tryardent.com/?ref=runtimewire and PostgresAI https://postgres.ai/?ref=runtimewire give agents isolated copies where they can test changes. Shapalov is taking a smaller position in that market. Pgbot inspects the database an operator already has. It provides no hosted dashboard, full telemetry service or isolated branch where an agent can rewrite schemas and run migrations. Pgbot's own documentation directs users who need alerts, fleet-wide views and long-term monitoring toward established platforms. A coding agent investigating a slow application often needs a trustworthy account of locks, query time, index usage and vacuum health before it needs authority to change anything. Pgbot packages that account into an interface agents can consume, with database permissions that keep the final operational decision with a human. For Shapalov, the bet is that a useful agent product can remain a tool: local, inspectable and difficult to misuse. Pgbot gives agents better evidence about production PostgreSQL while keeping their hands away from the controls.