By: Maxim Lukiyanov, PhD, Principal Software Engineer
Every feature in PostgreSQL has a story. Before a line of code lands, it's proposed, debated, reviewed and often rewritten on the pgsql-hackers mailing list, sometimes over years. That conversation has been going on in public since 1997, and its 645,000 messages hold the reasons behind most of PostgreSQL's design decisions.
It's one of the richest records of engineering knowledge I know of, and it's exactly the context AI agents need when they work on PostgreSQL or build on it. Agents can search the archive, but searching hundreds of thousands of messages takes them a long time, they can still miss the message that settled a question, and they have no map of how the facts connect: which thread led to which commit, which patch became which line of code, who argued for what, and what was finally decided.
So I built pghacker-mcp. It's a free, public Model Context Protocol (MCP) server that gives any AI agent the PostgreSQL community's design history and PostgreSQL's source code, every commit on every branch, connected in one knowledge graph, and it answers with citations you can check. There's no sign-in, and the whole project is open source. Fittingly, it's powered by PostgreSQL itself, running on Azure HorizonDB: PostgreSQL, the database, reflecting on PostgreSQL, the project.
With the PostgreSQL community gathering in Valencia for PGConf.EU 2026 this week, it felt like the right moment to share it. In this post, I'll show you what it can do, and then take you under the hood.
Ask PostgreSQL why
With pghacker-mcp connected, your agent can follow a feature from proposal to commit or revert, including the alternatives that were ruled out and why. It can also read, search and blame any version of PostgreSQL's code, back to the threads behind each line.
Every answer comes with citations to the messages, commits and lines of code behind it. For example, ask whether retrying a failed fsync() can lose data. Your agent will explain that it can, because on Linux a retried fsync() can report success after the first failure lost the data, and that in 2018 PostgreSQL chose to PANIC instead.
That's the real point of pghacker-mcp. Any agent can sound like it knows PostgreSQL's history. With pghacker-mcp, yours can show you where that history is written.
How it works
pghacker-mcp has three parts, built around one PostgreSQL database:
- The indexer, written in Rust, loads new mail and commits every hour and keeps the commit history and the graph up to date.
- Crawler agents, running on PilotSwarm, an open source durable runtime for agents from Microsoft, have read all 58,734 threads and recorded what each one decided: features, decisions and each author's positions, with verbatim quotes. Reading a 250-message debate and saying who argued what takes a language model, and it's what makes this project possible today.
- The MCP server, also in Rust, is public, stateless and read-only, with 17 tools: familiar ones like grep, read_file and blame, thread search, and a query tool for SQL and Cypher.
PostgreSQL turned out to be a great code search engine
Agents ask about code across time: how a function looked in 2015, who wrote a line, or whether a fix reached the back branches. That means pghacker-mcp needs every version of PostgreSQL's code, searchable fast.
That's a bigger challenge than it sounds. PostgreSQL's history has 105,000 commits on 39 branches, and the tree at an average commit holds about 2.6 million lines. Checked out one by one, they would add up to more than 250 billion lines. On my laptop, git log -S fsync_fname, which finds the commits that changed uses of PostgreSQL's fsync helper, takes about 54 seconds to search the whole history, and running git grep on every commit would take about six hours.
So the commit history stores each version of a line just once, with the range of commits that contain it. The idea is older than git. It's how SCCS stored every version of a file as one weave of interleaved deltas in the 1970s, and it's how temporal databases record the period in which a row is valid, here measured in commits, not time.
The trick is in how commits are numbered. Every commit gets a 64-bit address: master's commits are spaced 2³² apart, and each branch numbers its commits in the gap right after the commit it forked from. PostgreSQL's history has no merge commits, so the descendants of any commit form one continuous range, much as in the nested set model for storing trees in SQL. "Is this line in commit X?" becomes a simple range test on the line's bounds:
lo <= X AND X < hi AND (alive IS NULL OR alive @> X)
The int8multirange column alive covers the one exception: lines deleted on one branch but kept on another. With this model, all 105,000 commits fit in 24 million line versions, 6.5 GB with indexes.
What surprised me is that PostgreSQL already had every tool this design needs. The bounds are plain bigint columns, the same half-open interval an int8range describes, and int8multirange handles the exceptions. A B-tree on each line's file and bounds, (lineage, hi, lo), narrows a search to the files and commit you asked about. And a GIN index with pg_trgm's gin_trgm_ops narrows a regular expression down to a few candidate lines, which PostgreSQL then checks exactly. That's the technique Russ Cox described in how Google Code Search worked, and pg_trgm has supported it since PostgreSQL 9.3, thanks to Alexander Korotkov.
Together, these indexes search the whole history far faster than local grep can, because grep has to scan every version of the tree, while PostgreSQL's indexes go straight to the few lines that can match. pghacker-mcp finds every line that ever contained fsync_fname in every one of 105,000 commits, in 50 milliseconds.
Trigrams carry most of the load. I studied how AI coding agents actually search code, and of 35,728 real grep calls from my own agent sessions, 91% could use a trigram index, including 98% of those that spanned a folder or a whole repository. Nearly all of the other 9% searched files the agent had already named, where PostgreSQL simply reads those few lines.
Just as important, grep works exactly as agents expect. They can send pghacker-mcp the same grep commands they already write, flags, pipes and all. Replayed against GNU grep, 7,254 real grep commands from my agent sessions returned exactly the same output, every one. Agents don't need to learn a new search language: grep just works, on every version of PostgreSQL.
Everything else this project needs runs in the same engine: BM25 ranking and vectors for the mail, and a graph for the links. One SQL query can join them all. I never needed a separate search engine, vector store or graph database. I chose PostgreSQL to store the code, and it turned out to be a great engine for searching it, too.
A knowledge graph from the mailing list to the code
Search finds text. But questions about design are about connections: which thread a commit came from, which patch first proposed a line, who argued for what, and what was decided. Relationships like these are natural to express as a graph, so pghacker-mcp keeps them in a knowledge graph, built with Apache AGE in the same database: about a million vertices, from authors and messages to files and commits, and four million edges between them.
The most important design decision was who creates which links. Links that are facts are made by deterministic code. The Discussion: link that committers add to commit messages, or a message that mentions the commit, connects a commit to its thread; there are more than 40,000 such links. Patches posted to the list are matched to the lines and commits they became. Judgments, like what a thread decided and where each author stood, come from the crawler agents, and each one must quote its messages exactly, or it's rejected.
Here's the fsync story again, this time starting from the code:
One blame call takes a line of PostgreSQL 19 to its 2018 commit and to the patch where it first appeared. The commit's Discussion: link leads to the thread, and the thread to its decision. Three tool calls, from today's code to the debate behind it.
Because these connections are stored rather than rediscovered on every question, your agent can also ask what no single thread can answer: which features a file implements, who argued for or against each of them, which commits changed the file, and which release each feature shipped in or targets.
Search tells you where something was said. The graph tells you how it all connects: why the code is the way it is, and who shaped it.
MCP is growing up fast
In the last year and a half alone, MCP gained elicitation, structured output, tasks and extensions, and the 2026-07-28 revision made it stateless: no sessions, no handshake, and every request carries the client's capabilities. For a public server like pghacker-mcp, that's a big deal, because any server instance can answer any request.
But what excites me most are two newer features that change what a server can offer, and pghacker-mcp uses both.
Skills: a server that teaches agents
Tools give an agent abilities; skills give it know-how. An Agent Skill is a SKILL.md file of instructions that teaches an agent a workflow. The new official skills extension for MCP lets a server publish skills next to its tools, so agents that connect can discover and load them.
pghacker-mcp publishes one skill, review-as-author. Give your agent a patch and the name of a pgsql-hackers regular, and it reviews the patch the way that person likely would: each point backed by a quote of their own, marked as a prediction, and, given a date, based only on what they had written by then.
Ask your agent to review the May 2022 patch set for logical replication of DDL as Tom Lane would have, and it predicts he'd push back on putting it into core, quoting his own 2012 warning that decompiling parse trees would be "a permanent drag on every type of SQL feature addition". Tom actually raised that objection on this patch in March 2023, 80 patch versions later. That's feedback worth having early.
Clients that don't support the skills extension yet can load the same skill through a tool, load_skill_review_as_author.
Elicitation: a server that can talk to the user
Originally, an MCP server could only answer the model. Elicitation lets it ask the user a question directly, through a form the client shows, with the model taking no part. In the 2026-07-28 revision, it works as a multi-round-trip request: the server answers a tool call with input_required and a form, and the client retries the call with the user's answer.
I use it for something every public service needs: feedback. Once in a while, pghacker-mcp asks "Was the last answer helpful?", with 👍, 👎 or Skip. It asks at most once in an hour of use, backs off for a day if you decline, and never asks if you connect with ?feedback=off.
It sounds small, but it's a new interaction mode: a server that hears directly from the people it serves. I believe we'll see a lot more of this, from confirmations to choices to preferences. MCP is no longer just a way for agents to call tools. It's becoming a flexible protocol between servers, agents and the people who use them.
Why I built it on Azure HorizonDB
Everything I've described, from the mail and embeddings to the code history and the graph, lives in one Azure HorizonDB database: 29 GB on 32 vCores, running PostgreSQL 17 with pgvector, pg_trgm, pg_textsearch and Apache AGE. Even PilotSwarm keeps its agents' durable state there, and the indexer writes to it every hour while the public server reads.
Full disclosure: I work on the team that builds HorizonDB, so I'm biased. But this project shows what HorizonDB was designed for. HorizonDB separates compute from storage and sends only WAL from compute to storage, so I never had to provision storage or IOPS as the archive and the history grew. If the public server needs more read capacity, read replicas share the same zone-resilient storage instead of copying it. And because HorizonDB is built on PostgreSQL, every extension this project needed is there, and nothing in the code is specific to HorizonDB. One command runs the same project on your laptop, with PostgreSQL 17.
HorizonDB is in public preview and open to everyone. If you're building AI apps and agents on PostgreSQL, create a cluster and give it a try.
In conclusion
pghacker-mcp unlocks the PostgreSQL community's knowledge for every AI agent. With the commit history, your agent can search any version of PostgreSQL in milliseconds. With the knowledge graph, it can connect code to the debate behind it. And with skills and elicitation, a server can teach agents and hear from the people who use it.
To try it, add the server to your agent. In GitHub Copilot CLI or Claude Code, it's one command:
copilot mcp add --transport http pghacker https://pghacker-mcp.dev/mcp
claude mcp add --transport http pghacker https://pghacker-mcp.dev/mcp
pghacker-mcp.dev has the steps for the GitHub Copilot app, VS Code, Codex, Cursor and OpenCode. Then ask it something you've always wondered about PostgreSQL. The code is on GitHub: read it, file issues, contribute, and tell me how its answers work for you.
For nearly three decades, the PostgreSQL community has explained in public why PostgreSQL is built the way it is. Now PostgreSQL itself can help every agent, and every developer, find those explanations.
Microsoft