Key Takeaways

  • Craig Kerstiens warns that the ratio of application developers to database specialists has escalated from 10:1 twenty years ago to 100:1 today, and is approaching 1,000:1.
  • Software bootcamps and code generation tools train millions of engineers on application code, but almost none teach database administration or index design.
  • Adam Stacoviak argues that database engines could bridge this talent deficit by embedding autonomous AI agents directly into Postgres components like the query planner.
  • Kerstiens rejects adding AI into core database execution paths, comparing Postgres to a bank that requires absolute mathematical determinism rather than probabilistic models.

The Disagreement

Twenty years ago, database administrators controlled every aspect of production architecture. A developer writing code could not push a table migration or alter an index without running it past a dedicated specialist. As Craig Kerstiens recounted, “15, 20 years ago, you wouldn't make a change to the database without it flowing through a DBA. They controlled the database, how it worked, what queries ran. It flowed through them. They held the keys to the castle.”

Cloud providers and self-service infrastructure obliterated that gatekeeper model. Developers began spinning up isolated database instances on demand, pushing migrations directly from application codebases. Bootcamps popped up across the globe to teach JavaScript and Python, but none taught database internals. Kerstiens observed the widening gap: “We've never had boot camps for DBAs. That ratio of developers, but not experts on databases, if it was 10-to-1 before, now it's 100-to-1. It's about to be 1,000-to-1 of all these apps running that need database expertise on top.”

Because startups cannot find or afford DBAs, Adam Stacoviak suggested letting machine learning fill the seat: “DBA could be database agent, right? We are in an era where we could literally put an agent of some version of intelligence at the top of Postgres, like the planner, for example.” In Stacoviak's view, software agents could observe execution patterns and tune database operations automatically, protecting non-expert developers from their own configuration mistakes.

Kerstiens pushed back on putting probabilistic systems in charge of raw data storage. “Think of it like Postgres is your bank,” Kerstiens warned. “Do you want your bank to go AI everything, in reporting your balance and deposits?” Kerstiens argued that developers rely on Postgres specifically because it guarantees ACID compliance and deterministic execution. If an autonomous model intervenes in transaction planning, developers lose the ability to predict how queries will behave under load.

Who's Right (and When They're Wrong)

Kerstiens is correct about the database core. Postgres manages your source of truth. The approximately 50 committers who steer the project maintain strict engineering standards for good reason. If an autonomous planner tries to guess an execution plan based on probabilistic scoring and misjudges a table scan, a production cluster can lock up instantly. The upcoming Postgres 19 release focuses on deterministic capabilities like query plan pinning and concurrent table repacking, explicitly giving engineers tighter manual control over query stability, not less. Introducing non-deterministic AI agents into the transactional query planner contradicts the core reason teams choose Postgres.

At the same time, Stacoviak's diagnosis of developer behavior is accurate. Founders running small engineering teams will never hire a dedicated database administrator. They will continue to write queries through Object-Relational Mappers that omit critical indexes, create lock contention, and trigger sequential scans across tens of millions of rows. Telling these teams to simply learn database internals is wishful thinking.

Autonomous agents belong outside the engine rather than inside it. Advisory agents can sit in continuous integration pipelines and observability platforms. An agent can read slow query logs, spot missing indexes, and open pull requests for engineers to inspect before merging. Putting an agent in your code review workflow solves the DBA shortage without risking the deterministic guarantees of your storage engine.

What to Do With This

Log into your primary production database today and check whether the pg_stat_statements extension is enabled. Run a query to pull the top five queries by total execution time, identify any table performing full sequential scans without an index, and add the missing index in a manual migration tomorrow morning.