Coding Agents Are Pulling PostgreSQL Back Into the Spotlight

PostgreSQL has now topped Stack Overflow's Developer Survey as the most preferred database management system for four straight years, and its favorability ratings rose from last year. For a database that's around four decades old, that's a striking result. The more interesting question is what's driving it, and the answer my read points to is AI coding agents.

Agents are multiplying the number of databases

Phillip Merrick, co-founder and chief executive of pgEdge, puts it bluntly: PostgreSQL is "the default database for agent-generated applications," and "demand has skyrocketed." That's a vendor's view, but it lines up with a figure Databricks has put on the trend. Databricks says AI agents now spin up 80% of enterprise databases, as reported by Forbes.

The consequence is sprawl. When agents can create applications quickly, the number of databases to back them grows faster than the number of people available to run them. Merrick's version of the problem is simple: "You've only got a fixed number of human database administrators." Teams in this position typically feel the pressure first in operations, not in development, because each new prototype eventually needs backups, monitoring, access control and upgrades.

Why one engine is easier to live with

The argument for PostgreSQL in this context isn't only its reputation for stability and performance. It's the extensible architecture. AI has added new database features to the mix, including vector search, graph queries and agentic branching. Many teams have been tempted to adopt a separate engine for each one. PostgreSQL lets them add capabilities without that jump.

The clearest example is the pgvector extension, which stores vectors next to ordinary application data and searches for similar items. That matters for retrieval-augmented generation, where a model needs to pull relevant records before it answers. Keeping application rows and their vector representations in one system means retrieval can use transactions and joins, the same tools developers already use for everything else.

There's a second, less obvious factor. PostgreSQL's source code and documentation are public, which makes the engine easy for coding agents to learn from and build against. An agent that already knows the SQL dialect and the common patterns is less likely to produce something that falls apart in production. That's a reasonable hypothesis rather than a measured result, but it explains why the tool keeps coming up in agent-driven workflows.

The operations problem doesn't shrink on its own

Standardizing on one database reduces the number of technologies a team has to learn, but it doesn't make the workload smaller. A system with thousands of agent-built databases still needs someone watching it. That's where pgEdge is placing its bet on AI, this time on the administration side.

Its AI DBA Workbench monitors databases, flags issues and generates SQL to fix them, but only with a human administrator's approval. Merrick's example is a report whose runtime has stretched from minutes to hours. An agent can plausibly find a changed configuration setting or a missing index. The hard part is letting it investigate without giving it free rein to alter production.

That's the design question I'd keep an eye on across the whole category. pgEdge's answer has a few layers. Its SafeSession technology enforces read-only access at the PostgreSQL engine level, so the restriction doesn't depend on the agent behaving. Its Model Context Protocol server connects agents to database contents and schema information, which puts access controls inside the integration itself rather than in a wrapper someone might forget to configure. Enforcing permissions in the engine is a sounder pattern than relying on prompts to keep an agent in line, though it still needs careful setup and testing.

Where the databases run

According to the company, customers can prototype in pgEdge's cloud with the Starfleet platform and then deploy the same PostgreSQL distribution in a managed cloud, a customer-controlled cloud or on-premises. That range matters for teams where data residency or isolated networks limit where production can run. It also fits the growing interest in open-source and open-weight models that companies want to host privately, since the databases feeding those systems often have the same constraints.

Starfleet is aimed at the gap between a working prototype and a reliable production service, which is where many agent-built applications stall. The product description suggests the goal is less about adding AI features to PostgreSQL and more about making the operational path predictable.

What to watch

Here's the thing: PostgreSQL's momentum is real in the survey data, but the drivers are still forming. A few questions will decide whether this lasting interest turns into durable adoption. Will read-only enforcement and approval workflows hold up when agents manage fleets of databases rather than a handful? Will AI-assisted administration reduce the operational load, or will it shift the work toward reviewing machine-generated SQL? And how much of PostgreSQL's advantage comes from the engine itself versus the extension ecosystem around it?

Merrick's summary is confident: "For just about any data management problem, the answer is Postgres." Developers clearly agree with him for now. The next test is whether the operations side of the stack can keep up with the pace at which agents are creating new databases.