PostgreSQL earned its place in the modern application stack through openness: open source, open standards, an extensible engine, and a community that turns hands-on experience into shared progress. That formula still works. What is changing is the number and variety of people responsible for keeping PostgreSQL performant.
Developers now own more of the database lifecycle. Platform teams support larger estates. Smaller organizations often run business-critical PostgreSQL without a dedicated Database Administrator (DBA) on every team. The database has become more accessible, while deep operational expertise remains scarce.
That gap is where AI can have a practical impact. In Stack Overflow’s 2025 research, 70% of developers using agentic AI said agents reduced the time spent on specific tasks. The same research found that more than 75% still wanted human validation when they did not trust an AI answer. Those findings point to the operating model we should build for databases: more leverage, clearer evidence, and people firmly in control.
The need to democratize database expertise #
A PostgreSQL incident rarely arrives with a neat diagnosis. It arrives with questions: Why did this query suddenly slow down? Why are connections being exhausted? Did a deployment change the access pattern? Which metric matters? What should I investigate first?
Experienced DBAs have mental models for these moments. They know how to connect workload behavior, query plans, indexes, configuration, telemetry, and recent changes. Developers can learn those models, but production incidents are an expensive classroom.
The next evolution of PostgreSQL operations should make more of that reasoning available in the moment. This could help more teams understand what the database is telling them, decide what to do, and learn from the result.
From reactive to intelligent operations #
Traditional operations give teams dashboards, alerts, logs, runbooks, and documentation. Each source is useful. The difficult part is assembling the right context quickly enough to make a confident decision.
Intelligent operations can tighten that loop. Imagine an operating model that can observe relevant signals, investigate their relationships, explain a likely issue, recommend a next step, and preserve the evidence for review. Over time, the loop can extend to controlled execution and outcome verification, with authority bounded by policy and earned through successful results.
The important shift is from finding more signals to helping people reach better decisions. A developer should not have to become an expert in every PostgreSQL subsystem before they can begin a sound investigation. An expert should not have to repeat the same diagnostic process across hundreds of databases.
Moving from asked to answered #
At FabCon and SQLCon 2026 in Barcelona, Microsoft announced database agents for SQL and PostgreSQL on Azure, with preview availability. These AI-powered specialist agents are planned to be accessible in the Database Hub in Microsoft Fabric and in Visual Studio Code. They continuously observe and analyze database signals to help administrators investigate issues, understand performance bottlenecks, identify optimization opportunities, and accelerate troubleshooting.
Consider a slow query that begins affecting an application after hours. Today, the person on call may need to collect metrics, inspect active queries, compare recent changes, find the relevant plan, and search for a familiar pattern before asking an AI assistant a useful question. The quality of the answer depends on the quality of the context they can assemble under pressure.
Database agent changes the starting point. The investigation can begin with database context already in view. Instead of opening several tools to reconstruct the first part of the incident, the operator can begin with an issue, supporting signals, and a recommended direction to examine. That is the early value: compressing the distance between “something is wrong” and “here is what deserves attention.”
The open advantage #
The best agent experience should feel less like an opaque autopilot and more like a highly capable colleague who shows their work. It can bring specialized database knowledge into the workflow while continuing to leave architecture, risk, and production decisions with the people accountable for the system.
PostgreSQL’s openness is an advantage for intelligent agents. Its ecosystem contains decades of source code, documentation, extensions, operational practice, and community knowledge. An effective database agent can build on that foundation while preserving transparency. That means answers come with evidence. Recommendations explain why they fit the observed conditions. Proposed changes are reviewable. When confidence is limited, the agent makes it easy for a person to continue the investigation.
Progressive autonomy beats a leap of faith #
Microsoft has built database agent around progressive autonomy because database operations carry real consequences. The approach starts with observation and explanation, adds evidence-backed recommendations, and keeps users in control of actions, access, and operating boundaries. Results are verified and activity remains visible and auditable, so organizations can expand authority only where specific capabilities have proved reliable—and you’ll retain the ability to reverse course.
This is the approach we are offering to teams today, including those without deep DBA coverage. Database agent brings specialist guidance closer to developers without treating human expertise as optional. It also helps experienced operators scale proven practices by turning repeatable knowledge into governed skills that can work consistently across a database estate.
One pattern, more than one database #
PostgreSQL is one expression of a broader change across the Microsoft data estate. Database Hub in Microsoft Fabric is a single observability pane for supported databases, including Azure Database for PostgreSQL and Azure HorizonDB. The database agent experience in Fabric can surface prioritized findings across an estate and includes ready-made skills for agentic observability as well as integrations with tools such as SQL Server Management Studio and Visual Studio Code.
That broader direction matters because operational problems do not respect product boundaries. Teams need familiar ways to investigate, govern, and act wherever their data lives. Specialized agents and skills can bring the right knowledge to each engine while creating a more consistent operating model across tools.
Keep PostgreSQL open. Make expertise abundant. #
PostgreSQL’s future will continue to be shaped by the community, by extensions, and by the people who understand how the system behaves under real workloads. AI gives us a new way to extend the reach of that expertise.
We can move from operations that are largely reactive and expertise-dependent toward workflows that are proactive, evidence-rich, and increasingly agent-assisted. We can help a developer know where to begin, help a DBA scale what they know, and help a platform team carry learning from one incident into the next.
The future of PostgreSQL operations is about putting more PostgreSQL expertise within reach of every team member. Database agent makes that future tangible today, while building toward a more automated model where specialized skills and remediation actions help developers operate databases more intelligently. It will preserve what developers value most: choice, transparency, control, and a clear view of what the database is doing.
Contact your Microsoft Azure representative if you’re interested in joining the preview and stay tuned for updates as Microsoft Azure continues to bring database context and AI-assisted workflows closer to developers and operators.
Explore Database Hub #
Discover how Database Hub helps you monitor database health, review security posture, and simplify database management across environments.