Agents are creating databases for a fixed number of administrators, pgEdge's CEO says

A report whose runtime has stretched from minutes to hours is the example Phillip Merrick gives of the work that lands on a database administrator ^[8]. Merrick is co-founder and chief executive of pgEdge ^[10]. In SiliconANGLE's account, an agent might trace the slowdown to a configuration change or a missing index ^[8].

Merrick's larger claim is that PostgreSQL has become the standard output of coding agents. "It's the default database for agent-generated applications," he said in an interview ^[11]. His company is a vendor building its business around PostgreSQL deployments, so the claim comes from an interested party ^[10].

The two figures SiliconANGLE sets beside it measure different things. Stack Overflow's survey records what developers say they prefer, and PostgreSQL has topped it four years running ^[1]. Databricks counts the databases agents create, and puts agents at 80% of enterprise databases ^[14]. SiliconANGLE's report does not split that 80% by engine, so nothing in it shows how often an agent picks PostgreSQL.

The comfortable assumption is that a popular engine means a tidy estate. Merrick describes a different problem. "A lot of people don't realize that this explosion in agentic application development is creating an explosion in the number of databases to manage," he said ^[12]. He added: "You've only got a fixed number of human [database administrators]." ^[13]

We think teams should plan for the count of databases first and the engine second. Standardizing on PostgreSQL is a defensible default for new agent work. Merrick asserts it can lower training and management overhead ^[5], and keeping records and vectors in one engine reduces the number of database technologies a team must learn and operate ^[4]. The tradeoff is that the saving is in skills. SiliconANGLE notes that simplifying the technology portfolio does not necessarily simplify the workload ^[6].

For Monday, sort every agent-created database on two questions: is it headed for production, and does a named person own it? A prototype with no owner gets an expiry date. A prototype with an owner can stay as it is. A production-bound database with no owner does not deploy until someone signs for it. One with an owner goes into the inventory, and the agent's access stays at reading until a person approves a change, the same approval step pgEdge builds into its own tool ^[7].

Run the count before adopting any of this. The 80% is Databricks' figure for enterprise databases in general, and the only way to learn your own share is to list what exists and who created it ^[14].