A morning in Valencia

On Friday, 23 October 2026, the last day of PGConf.EU in Valencia, almost 40 practitioners, builders, and skeptics gave up a community-day morning to ask one question: how real is “Autonomous Postgres” today?

Marc Linster, Ryan Booz, and I organized the session as a working session, not a showcase. Ryan helped shape the agenda but couldn’t join us on the day. Marc has already shared his reflections, and I recommend reading them. This post is my own take: what I heard, the patterns I saw running underneath six very different talks, and where I think we, as a community, should build next.

Postgres is slowly changing from a system that DBAs operate to a system that increasingly operates itself. The talks showed that this change is already underway. They also showed where the real gap is.

Postgres is already one of the most trusted databases in the world. It doesn’t lose committed data, and it doesn’t hide what it did. The gap is that it can’t yet explain itself to an agent.  What an agent needs to know depends on its job. A backup agent doesn’t need to know what “revenue” means, and an analyst agent doesn’t need the state of the WAL archive. But every agent needs its own slice of five things: what the system has, how it is organized, what the data means, how it normally behaves, and what it is allowed to change. Today, much of that knowledge lives in DBAs’ heads, runbooks, and dashboards, not in Postgres.

So the hard part is not making Postgres smarter. It is making Postgres legible: able to describe itself well enough that an agent can be trusted to act on it.

What an agent needs to knowWho needs it mostWhat Postgres exposes todayWhat’s missing
What the system hasEvery agentCatalogs: databases, tables, indexes, extensions, settingsLittle; this is Postgres’ strength
How it is organizedVacuum, backup, and tuning agentsConstraints, dependencies, partitions, replication slots and viewsIntent: why it is built this way, and what is off-limits
What the data meansAnalyst and governance agents; a backup agent barely needs itCOMMENT ON, often empty or staleApproved definitions with an owner
How it normally behavesOperational agents: vacuum, tuning, anomaly detectionpg_stat_* views, mostly cumulative countersBaselines and history: what is normal for a Sunday at 3 a.m.
What could be better, and what is allowedEvery agent that actsPlanner, auto_explain, HypoPG, grantsRanked opportunities and a catalog of actions this agent may safely take

Call it least knowledge, the sibling of least privilege: give each agent the slice its job requires, and nothing more. That keeps its context small and accurate, and it limits what a confused or compromised agent can leak. The list also maps directly to the primitives I propose later in this post.

The frame: three corners of one triangle

Marc and I opened the morning with a simple picture. We expected “Autonomous Postgres” to show up in three places, with Postgres in the middle of all of them.

  • AI for the analyst. Helping people turn questions into queries and reports, so the citizen analyst can get value from data without being a SQL expert.
  • AI for the DBA. Supporting the people who keep Postgres healthy: tuning, performance, root-cause analysis, and security.
  • AI-based value generation and governance. Postgres as the system of record for AI itself: facts, state, permissions, audit, and the context an agent reasons over.

The frame held up, but not in the way we expected. Hardly any talk stayed in one corner. Most sat on an edge between two, and every one of them leaned toward the top corner. In practice, governance was not a separate category. It was the force holding the other two together.

TalkAnalystDBAGovernance
Anil Kumar & Rajesh Nagpal: Autonomous Postgres✓✓✓
Luigi Nardi: Peeking inside the black box✓
Matt Yonkovit: Postgres needs an agent loop✓✓
Dave Page: An agent you’d trust at 3am✓✓
Divya Sharma: Building an AI agent which detects and resolves PostgreSQL Transaction ID wraparound✓✓
A. Bilge Ince: Your database has no idea who is asking✓✓

Why three corners, and what the triangle leaves out

We chose three corners because they map to who benefits: the person asking questions, the person keeping the system healthy, and the organization that has to answer for what AI does. Each corner also had working examples we could put on stage in a half-day session. The triangle is a starting map, not the whole territory. Four things it leaves out deserve their own attention:

  • The developer. AI that reviews schema changes, migrations, and queries before they reach production. This is the cheapest place to prevent the incidents the DBA corner later cleans up.
  • The fleet. As Anil’s slides noted, agents now create databases, branches, and load nobody planned for. Autonomy across hundreds of instances is a different problem from autonomy on one.
  • The data owner. Meaning needs someone who approves it. In Anil’s words: an index waits for the DBA; a definition waits for the data owner.
  • Agents as a workload. Agents don’t only help run Postgres; they also hit it with bursty, exploratory queries. Capacity planning, connection limits, and cost controls have to account for them.

There are also two axes the triangle doesn’t show: how autonomous (observe, advise, act with approval, act within policy, self-driving) and where the reasoning runs (inside, outside, or both). Together they give three questions I’d ask of any autonomous Postgres project: who does it serve, how far may it go, and where does it run?

What we heard

Autonomous Postgres: from self-managed operations to an AI-ready data platform

Rajesh Nagpal and Anil Kumar

Rajesh described AI as resting on three pillars: the model (intelligence), the agent (action), and the context (knowledge). He then walked through what it takes to bring all three into Postgres, using two examples: a sales question answered over MCP, and a DBA copilot that turns a 3 a.m. alert into a matching runbook step with the real PIDs and SQL already filled in. In both cases the human still decides.

Anil then made the line that stayed with many of us: the best observer of Postgres is Postgres. Tools outside the database see the query text, how long it took, and the plan it finally ran. Only the planner knows why it chose that plan, which ones it rejected, and where estimates and reality diverged. The pieces already exist in pg_stat_statements, auto_explain, HypoPG, and pg_plan_advice in PostgreSQL 19. “It’s time to connect them.”

Two more ideas from their talk shaped the rest of my morning:

  • Autonomy is gated by reversibility, not by intelligence. Using the autonomy levels Marc and Luigi Nardi presented at pgDay Paris 2026 (observe, advise, act with approval, act within policy, self-driving), they argued that agents should climb those levels in the order their actions can be undone. Creating an index is cheap to undo. Changing schema or data is a human decision.
  • Don’t out-reason the frontier model. Out-context it. “A wrong query doesn’t throw an error. It returns a number.”

Peeking inside the black box: a statistical approach to parameter importance – Luigi Nardi

Luigi brought the scientist’s discipline. On a real RDS production system he showed 787 distinct query IDs in a two-hour window, with more than 1.8 million seconds of total execution time. Which of those matter, and which configuration parameters actually move them?

His answer combined an LLM with statistical rigor. Group the workload into heavy-and-frequent, light-and-frequent, and light-and-infrequent queries, then use proven statistical methods to separate real parameter effects from noise and workload variability. The LLM is useful, but the statistics are what make its recommendations trustworthy.

Postgres needs an agent loop – Matt “The Yonk” Yonkovit

Matt asked what autonomous database operations actually require, and answered with an agent-loop runtime that lives inside Postgres. Agent definitions and agent state are stored in the database, so invoking an agent starts to look much like calling a stored procedure.

That placement is the point: the agent inherits Postgres’ roles, transactions, and audit for free. It was the boldest “inside the database” position of the day, and it gave the later discussion its sharpest edge.

An agent you’d trust at 3am – Dave Page

Dave opened with a scene: 03:47 on a Sunday, checkpoints firing twice the safe rate, a one-statement fix that a capable model could find. Who would let it run unsupervised? Nobody raised a hand, “including me, and I sell this.”

His argument: a smarter model does not close the gap. Confident wrongness, non-determinism, no memory of past mistakes, and untrusted context all remain. Trust is a property of the system, not the model. So Ellie, the assistant in pgEdge’s open-source AI DBA Workbench, runs outside the database and works through 21 typed tools rather than a raw SQL prompt (“you cannot RBAC a text field”). Writes are gated behind approval, queries are validated against the server to catch hallucinated identifiers, and Postgres’ own roles constrain what she can touch.

Dave was also honest about what is still missing: a critic agent, impact previews, an undo captured with every fix, post-execution checks, outcome recording, and a durable audit trail. He also listed one thing PostgreSQL itself owes us: a real read-only mode for connections. default_transaction_read_only can be switched off by the user, and it does not stop C functions or loopback connections through dblink or postgres_fdw. His model for autonomy is a dial, not a switch: you move from approving each action to setting the policy and reading the log. “It woke me anyway” is a feature, not a failure.

Building an agent that detects and resolves transaction ID wraparound – Divya Sharma

Divya took one of Postgres’ oldest fears and built a calm, deterministic answer. Her agent does three things:

  1. Detect: age is past autovacuum_freeze_max_age and vacuum is blocked or pinned, not merely slow.
  2. Act only where allowed: each blocker type has a verdict the DBA sets in policy, either auto or advise. Protected users, apps, and slots are never touched.
  3. Page everything else: for advise verdicts, standbys, and unknowns, a human gets the evidence and the exact SQL to run.

Three design rules underpin it: stateless (nothing stored between runs), policy first (the default verdict is advise), and one role (the agent checks its own grants). Whatever the model contributes, the decision to act is never left to it: it comes from a verdict the DBA set in advance. For a well-understood failure mode, that is exactly right. To me, this was the clearest working example of governance as design rather than decoration.

Your database has no idea who is asking – A. Bilge Ince

Bilge started where many teams start: an agent that answers “What’s the revenue per customer in 2025?” Text-to-SQL looks solved on clean academic benchmarks, with scores above 90% on Spider. On real private warehouses (BEAVER), accuracy drops to around 11%. The problem is not the model. It is proprietary data, schemas that drift over time, and real-world complexity.

Her team’s path was a chain of fixes, each one uncovering the next problem. Restricted MCP access was necessary but not sufficient: restricted access is not smart access. COMMENT ON helped, but only when the comments were good. Rich comments improved column recall by 0.25, while thin comments were close to noise. Embedding those descriptions made meaning searchable. Join hints from pg_constraint found a correct join in the top 10 results for 86% of multi-table queries. Trusted, parameterized “aliases” let recurring questions skip SQL generation entirely.

Then came the trust layer. By tagging every connection with a purpose through application_name, the DBA can see who is asking and why in pg_stat_activity, a view they already know how to read. Her closing line was hopeful: none of this needs new infrastructure, because the pieces are already in Postgres.

Four patterns underneath the talks

1. Inside versus outside is a spectrum, not a fork

The liveliest debate of the morning was whether AI processing belongs inside the database. Supporters pointed to Postgres’ audit, RBAC, and transactions. Skeptics worried that putting reasoning inside the operational core could put Postgres’ robustness and integrity at risk.

Listening to all six talks, I saw a spectrum rather than two camps:

  • Agent lives inside: Matt’s agent loop, and the in-database agents and context in Rajesh and Anil’s talk.
  • Agent outside, meaning inside: Bilge’s semantic knowledge base, comments, join hints, and trusted queries, all stored in Postgres.
  • Agent outside, bounded by Postgres: Dave’s Ellie and Divya’s wraparound agent, constrained by roles, grants, and policy.

The common ground is more useful than the disagreement: observe from inside, decide under policy, act through narrow doors. Wherever the reasoning runs, the evidence and the boundaries belong in the database.

2. The model proposes; something else decides

It is tempting to file Divya’s and Luigi’s work as the “no LLM” talks. That misses what they actually share: where the model sits. In both, the model helps to detect, explain, or propose, but the decision rests on something a human can inspect. In Divya’s agent, the verdict comes from a DBA-set policy (auto or advise), and protected users, apps, and slots are never touched. In Luigi’s work, recommendations must be backed by statistical evidence that holds up against noisy workloads.

That is the pattern I’d copy. An agent is a loop that uses a model, but the model shouldn’t be the judge. The judge is policy, rules, or statistics.

3. Trust is earned in the order things can be undone, but “cheap to undo” is a trap

Dave’s dial, Divya’s auto-or-advise verdicts, and Anil and Rajesh’s reversibility ladder all say that autonomy is a track record, not a switch. I agree with the direction, but the ladder needs more than one dimension.

Take the bottom rung: creating an index. Dropping it is one statement, so it looks cheap. But on a busy, multi-terabyte table, a plain CREATE INDEX blocks writes for the entire build. CREATE INDEX CONCURRENTLY avoids that, but it runs longer, scans the table twice, waits for older transactions, and generates heavy I/O and WAL that can push replicas behind. If it fails, it leaves an invalid index behind. Once built, the index adds cost to every insert and update, and it can change plans for queries nobody was watching. Even DROP INDEX takes an exclusive lock unless it runs concurrently. Started at 11 a.m. on month-end close, the “cheapest” action on the ladder can be the most expensive event of the day.

The real cost of an action is not its type. It is reversibility, blast radius, and timing together:

DimensionThe questionFor a new index
ReversibilityHow quickly and completely can we go back?The drop is quick; the hours of load and replica lag are not refundable
Blast radiusWhat else does it touch: one query, one session, one table, the cluster, the replicas?Every write to the table and every plan that reads it
TimingWhen does it run relative to peak load, batch jobs, and maintenance windows?Harmless at 3 a.m. on Sunday; painful at month-end close

So what is actually cheap? Two kinds of action sit at the bottom of the ladder, for different reasons. Some are reversible: SET LOCAL, a hypothetical index in HypoPG, an EXPLAIN, or a reloadable parameter scoped to one table, role, or database. Others are non-destructive: a plain VACUUM or ANALYZE changes no data, so there is nothing to undo, and it can simply run again. These are the natural first rungs for an agent, and most routine operational work lives here.

Even these need a scope and a clock. Vacuum consumes I/O and generates WAL. Its final truncation step briefly takes an exclusive lock that can cancel queries on standbys, and VACUUM FULL is a complete table rewrite. ANALYZE can flip plans. A parameter can be reverted in seconds, but a cluster-wide change to work_mem or random_page_cost changes plans everywhere at once. A higher work_mem across many concurrent queries can exhaust memory, and settings such as shared_buffers need a restart. Physical changes such as indexes, table rewrites, and schema changes come last, inside a planned window, after a preview of locks, duration, and WAL.

The pragmatic ladder, then, is: simulate, scope narrowly, schedule, then act. Agents should climb by blast radius and timing, not by action type alone.

4. Meaning is the missing layer

The analyst corner turned out to be the least mature. Text-to-SQL works on clean benchmarks and struggles on real schemas. Both Bilge and Anil arrived at the same fix: don’t ask the model to guess meaning. Store it in Postgres, have the data owner approve it, and give the agent only what the question needs.

What the room asked for

At noon we opened the floor with one question: what should we build next? A quick roundtable gave everyone a voice. Marc’s summary of the priorities matches what I heard:

  1. Governance, security, and risk management
  2. Shared standards for guardrails and trust
  3. Context for AI
  4. Frameworks and education, including “golden examples” of good practice

One participant summed it up: “AI is like a stick of dynamite. Powerful and useful, but also very dangerous.”

The comments on Marc’s post added nuance. Greg Clough put it plainly: we can either focus our efforts and guide the conversation, or get run over by the AI steamroller. Kanchan Mohitey asked the community to share where autonomy falls short, not just where it succeeds. I agree with both.

From consensus to primitives

The room agreed that governance comes first. But a consensus on a slide does not stop an agent at 3 a.m. Governance has to become something Postgres provides, not something every team rebuilds in its own lab.

The good news is that most of the parts already exist. Every speaker reached for the same ones: roles, grants, COMMENT ON, pg_constraint, application_name, pg_stat_statements, transactions. What is missing is the connective tissue that turns those parts into primitives an agent can rely on and a DBA can reason about. Here is my proposal for discussion:

PrimitiveThe question it answersBuilding blocks todayWhat’s still missingSeen on stage
1. Agent identity and purposeWho is asking, for whom, and why?Roles, SET ROLE, row-level security, application_nameA native “acting on behalf of” chain and a declared purpose per sessionBilge’s purpose-tagged connections
2. A true read-only boundaryCan this connection change anything at all?default_transaction_read_only, grants, extensions such as pgedge-safesessionA read-only mode the session cannot turn off, covering C functions and loopback connectionsDave’s “what PostgreSQL owes us”
3. Policy verdictsAct automatically, advise, or never touch?GRANT, event triggers, security labelsA declarative auto / advise / deny verdict per action class, with advise as the defaultDivya’s policy-first agent
4. Planner explainability as dataWhy this plan, and where did estimates go wrong?pg_stat_statements, auto_explain, pg_plan_advice (PostgreSQL 19)Rejected plans and estimate-versus-actual drift, queryable as tablesAnil and Rajesh’s “best observer”
5. What-if before doWhat happens if we make this change?HypoPG, EXPLAIN, SET LOCAL, transactional DDLOne simulation step that returns cost, lock, and duration before any writeDave’s impact preview
6. Approved meaningWhat does this data mean, and how should it be queried?COMMENT ON, pg_constraint, trusted parameterized queriesA standard, versioned semantic layer with proposed and approved statesBilge’s semantic knowledge base; Anil’s approval loop
7. Provenance and undoWho acted, on what evidence, with what result, and how do we reverse it?pgaudit, event triggers, logical decoding, savepointsA durable action ledger that records the rollback with every change and outlasts a model swapDave’s audit trail; Anil and Rajesh’s reversibility ladder

Holding it all together is a shared, open MCP contract for Postgres: standard read tools, gated write tools, and a clear mapping from each tool to a role, a verdict, and an audit record. Marc hoped we would converge on one or two accepted approaches instead of “doing the same things in 20 different labs.” I strongly agree. With a shared contract, the inside-versus-outside debate matters much less, because every agent goes through the same audited doors wherever it runs.

The dynamite metaphor works here too. Dynamite moved mountains only once it came with fuses, blasting caps, and rules for handling it. These primitives are Postgres’ fuses.

What comes next

Anil closed his talk with a line I keep coming back to: autonomy isn’t a feature you ship. It’s trust you earn. The Postgres community has always earned trust slowly and deliberately, one careful commit at a time. That patience is exactly what this moment needs.

I’d like to keep this conversation going beyond one morning in Valencia, and turn it into shared work. Some concrete steps:

  • A follow-up series. Marc and I plan to explore these ideas in more depth, one corner of the triangle and one primitive at a time, ideally co-written with the speakers.
  • A working group on a shared Postgres MCP contract, starting from the tools and guardrails that already exist in open-source projects.
  • A public collection of failure stories. As Augustine suggested, where autonomy fell short is as valuable as where it worked. Dave already invited people to “bring us the incident that breaks it.”

Three questions for you:

  1. Where does your work sit on the triangle: analyst, DBA, governance, or an edge between them?
  2. Which primitive would you build first, and what have you already stitched together in your own lab?
  3. Would you join a working group on a shared MCP contract for Postgres?

Reply in the comments, find me on LinkedIn, or bring your answer to the next Postgres event. The best ideas from that room deserve a second morning.

Resources

Thank you to Rajesh, Anil, Luigi, Matt, Dave, Divya, and Bilge for sharing their work so openly. Thank you to Marc and Ryan for organizing with me, and to the PGConf.EU organizers and everyone in the room for making it a working session rather than an audience.