PostgreSQL – A Database Phoenix Story
Back in November 2025 at Ignite, Microsoft announced “the preview of Azure HorizonDB, a fully managed Postgres-compatible database service.” At Build 2026, Microsoft announced Public Preview of HorizonDB. Let’s see why Microsoft is launching a product that can potentially cannibalize their MS SQL.
Microsoft already had Azure Database for PostgreSQL Flexible Server. However, HorizonDB is not just another pure PostgreSQL instance – it is Microsoft’s attempt to rebuild the infrastructure underneath PostgreSQL while preserving the interface above it. HorizonDB separates compute from storage, makes the compute layer largely stateless, and uses a database-as-a-log architecture in which the write-ahead log, or WAL, becomes the authoritative source of database states. Storage services reconstruct data pages from that log, while compute nodes concentrate on query and transaction processing.
That distinction is not cosmetic. It is the reality of building a next-generation database platform. HorizonDB was never really a story about Flexible Server’s inadequacy. It was a story about what Postgres had quietly become, and about a fight none of the major clouds could afford to lose.
An Elephant That Almost Wasn’t
PostgreSQL’s roots go back to 1986, when Michael Stonebraker began the Postgres project at UC Berkeley as a successor to his earlier Ingres database. Stonebraker explored ideas that conventional relational databases of the period did not handle particularly well: complex data types, extensibility, rules, object-relational structures, and support for data that did not fit neatly into rows of simple numbers and character strings.
Its formal development ended with version 4.2 after the growing user community created a support burden that distracted Stonebraker from research work. In 1994, Andrew Yu and Jolly Chen added a SQL interpreter and released the resulting system as Postgres95. In 1996, it was renamed PostgreSQL to reflect the marriage of the original Postgres architecture with SQL.
And in 1997 a database needed a face. The mailing-list debate among surviving accounts over what that face should be was unexpectedly heated. A community member named David Yang proposed an elephant, inspired by Agatha Christie’s novel Elephants Can Remember. The logic was almost too neat to be a coincidence: a database’s entire job is to remember things reliably, for a long time, and elephants are, across nearly every culture, the animal associated with never forgetting. A designer in St. Petersburg, working with Postgres advocate Oleg Bartunov, drew the elephant that became iconic: a calm blue figure, later vectorized and cleaned up by a Swedish developer for the early commercial Postgres website.
Through the late 1990s and 2000s, Postgres lost the popularity contest badly. MySQL became the default choice of the web era – simpler to set up, lighter, and backed by aggressive commercial support from Sun and Oracle. On the enterprise side, Microsoft SQL Server and Oracle Database owned the boardroom, bundled with tooling, certifications, and decades of vendor relationships. Postgres was respected among database purists for its standards compliance and correctness – but respected is not the same as chosen. For two decades, it was a technically superior option that lost anyway.
What changed wasn’t a single event but a slow accumulation of the right features arriving just before the right moment needed them. Postgres’s extensibility – what made it “the elephant that remembers” – let the community bolt on capabilities no single vendor roadmap would have prioritized: JSON and JSONB support that let it swallow document-database workloads without giving up transactional integrity; PostGIS for geospatial data; time-series extensions; foreign data wrappers that let a Postgres instance query almost anything else. It became, in effect, a database that could hold multiple formats and data models under one roof with one query language and one set of operational guarantees – a multi-format, metadata-first system before anyone was framing it in those terms.
Then came pgvector, an extension letting Postgres store and search vector embeddings natively, which arrived at almost exactly the moment enterprise AI needed a place to keep both structured business data and AI-generated embeddings in the same transactional store. Suddenly the 20-year-old all-remembering elephant became the most natural home for agents that needed to remember everything too: conversation history, tool-call state, retrieved documents, embeddings, and the underlying business records – all consistent, all query-able, all in one place.
Why Build Another Postgres?
Traditional PostgreSQL was designed around a comparatively monolithic model: the database engine, memory, transaction log, data pages, checkpointing, and local storage all operate as parts of one tightly coordinated system. HorizonDB pulls that system apart. It requires a purpose-built WAL service, distributed page storage, WAL filtering, shared durable storage, caching, sharding, replication, and failover mechanisms that still preserve PostgreSQL transaction semantics. Microsoft describes a system in which only WAL is written from compute into the storage layer, storage nodes reconstruct pages by applying the log, and replicas share the underlying durable data. This is a materially larger engineering undertaking than placing open-source PostgreSQL on managed virtual machines.
This is what’s required in a world where AI agents themselves are the primary client of a database, issuing bursts of small transactional reads and writes, storing embeddings and structured records and conversation state in the same place, and needing that state to survive and be recalled with near-zero latency, indefinitely, across millions of concurrent sessions. To solve that, Microsoft (and earlier Amazon and Google) had to keep the interface – the tables, the SQL, the drivers, the extension ecosystem developers already trust – but replace the guts, truly separate storage from compute, build a cloud-native storage layer that can scale reads independently, fail over in milliseconds, and survive zone outages without blinking.
In other words: Microsoft didn’t build HorizonDB because Postgres on Azure was failing. It built HorizonDB because Postgres on Azure was winning – winning so decisively as the default choice for new application development, and increasingly for agentic AI workloads specifically, that shipping only a “compatible” managed instance was no longer a credible competitive position against Amazon’s Aurora and Google’s AlloyDB. If the elephant was going to carry the next decade of cloud workloads, Microsoft wanted to build the right legs for it.
The Elephant in Everyone’s Cloud
Other participants in the race:
Amazon moved first among the hyperscalers, building Aurora PostgreSQL – a proprietary, log-structured, distributed storage engine underneath standard Postgres – explicitly designed to outperform stock Postgres at cloud scale while keeping the ecosystem’s drivers and tooling unchanged.
Google followed with AlloyDB, its own PostgreSQL-compatible service using a disaggregated, columnar-accelerated storage layer aimed at closing the gap between transactional and analytical performance without leaving the Postgres interface.
EnterpriseDB (EDB) took an older, quieter path: Since 2004, it has built its business specifically on making Postgres a credible landing spot for enterprises fleeing expensive Oracle licenses, developing an Oracle-compatibility mode (Enterprise Postgres) that lets Oracle-written applications run against Postgres with minimal rewriting – effectively turning the “elephant” into a migration bridge out of the very proprietary databases that once outcompeted it.
Oracle offers “OCI Database with PostgreSQL,” described as combining open-source PostgreSQL with OCI’s infrastructure, using a proprietary “Database Optimized Storage” layer for performance – architecturally similar in spirit to what Microsoft is doing with HorizonDB and to AWS Aurora.
IBM Cloud has a dedicated “Databases for PostgreSQL” service. However, IBM’s relationship to Postgres looks more like “we’ll let you bring/connect it” than “we’re betting our platform on it” – a meaningfully different posture. IBM’s strategic center of gravity for OLTP remains Db2, with Postgres offered mainly for compatibility/flexibility reasons in the cloud catalog.
Within weeks of each other in 2025, the data platform world’s two fiercest rivals made the same bet at almost the same time:
- Databricks acquired Neon, a serverless Postgres startup. Databricks noted that roughly 80% of the databases Neon customers provisioned were being created automatically by AI agents rather than by human developers, a statistic that captures exactly why the acquisition happened.
- Snowflake answered with its acquisition of Crunchy Data, a more enterprise- and Kubernetes-hardened Postgres provider, launching “Snowflake Postgres” to bring transactional, agent-ready operational data directly into its AI Data Cloud.
As we reported earlier, this is not about analytics anymore, but about immediate availability of operational and analytical data for enterprise AI.
What Agentic AI Needs to Remember
Besides a traditional database that merely stores the latest customer balance or order status, agentic AI applications need a database that can retain the context:
- What happened
- Which person, service or agent caused it
- Which document or event informed a decision
- What permissions were in effect
- Which version of the data was used
- Which tool was called
- What the tool returned
- How the current state relates to everything that came before it
PostgreSQL is becoming the database that remembers everything.
That statement is a metaphor, not a literal storage guarantee. PostgreSQL’s old row versions can be removed through vacuuming, and WAL can be recycled according to retention and backup policies. An application that requires permanent history must deliberately preserve events, audit records, provenance, and recovery copies. But PostgreSQL supplies unusually strong foundations for building such an application memory: transactional consistency, multiversion concurrency control, write-ahead logging, logical replication, and a data model that can retain structured state, semistructured evidence, and searchable representations together.
The elephant remembers what the architect tells it to remember.
PostgreSQL’s Suitability for Agentic AI
PostgreSQL’s suitability for agentic AI does not begin with vector search. It begins with its data model.
A conventional business application may need customer, order and entitlement tables. An AI agent working inside that application also needs conversation state, instructions, tool definitions, document fragments, API responses, embeddings, confidence values, timestamps, identity information, security policies, and evidence supporting its conclusions. PostgreSQL can hold these different representations within one governed transactional environment. Extensions such as pgvector add vector similarity search to that same environment.
This gives PostgreSQL a multiformat character without requiring an application to abandon relational discipline. A developer can place durable business identifiers and controls in relational columns, retain variable attributes in JSONB, index source text for lexical search, store embeddings for semantic retrieval, and relate all of it through keys and transactions.
That combination is particularly valuable for agents. An agent rarely needs vector similarity alone. It usually needs vector similarity constrained by structured metadata to:
- Retrieve semantically similar policies, but only from the applicable jurisdiction.
- Find relevant customer interactions, but only for the authenticated customer.
- Locate comparable incidents, but only from approved data sources.
- Recommend an action, but only when the user’s role permits it.
- Retrieve current information while preserving the source, timestamp, and version used.
PostgreSQL can combine those filters, joins and retrieval methods in one query plan rather than forcing an agent to reconcile separate relational, document, search, and vector stores.
Its metadata story is equally important. PostgreSQL’s system catalogs store schema metadata, and internal bookkeeping information as ordinary relational tables. Tables, columns, types, constraints, indexes, roles, policies, functions, extensions, and dependencies are represented in query-able catalogs.
“Metadata-first data capture” is not an official PostgreSQL product feature. It is an architectural pattern encouraged by PostgreSQL’s design: capture a business object together with its meaning, ownership, type, provenance, constraints and relationships, and keep that metadata accessible to applications and governance tools.
For agentic systems, that distinction matters. Large language models can generate plausible language without understanding whether they are authorized to act, whether the information is current, or whether a result came from an approved source. A metadata-rich database gives the surrounding application a place to enforce those boundaries.
PostgreSQL does not make an agent trustworthy by itself. It gives developers a practical place to persist the context from which trustworthy behavior can be engineered.
Every Quarter Matters – But the Database Is Not the Whole Decision
As of September 2026, HorizonDB remains in public preview, and Microsoft’s public pages do not state a general-availability date.
The delay is understandable. A new storage and recovery architecture must be tested under failures, regional disruptions, upgrade events, capacity spikes, long-running transactions and many combinations of PostgreSQL extensions and client behavior. Database trust is accumulated slowly and can be destroyed by one poorly handled incident.
At the same time, every quarter of waiting gives Aurora and AlloyDB another quarter to increase their footprint. Every new production workload creates schemas, integrations, operational procedures, security controls, support relationships and developer expertise. In competitive and multi-cloud accounts, that accumulation can materially weaken Microsoft’s position.
Most enterprises, however, will not select a database in isolation. The database is only one part of the decision. Enterprises also consider identity, networking, security, developer tooling, Kubernetes, observability, analytics, AI models, commercial commitments, skills, and data gravity.
This is why the emerging contest is not primarily a database-platform war – it is a war among cloud platforms, with PostgreSQL serving as a common application interface inside each one.
What CIOs Should Evaluate
CIOs should resist evaluating HorizonDB through a single throughput figure. A database with a better compute benchmark can still be the more expensive or less resilient option once the full operating model is included.
- Resilience and recoverability should come first. Buyers need explicit recovery-time and recovery-point objectives, regional-failure architecture, backup-retention choices, deletion recovery, documented failover behavior and evidence from actual failure exercises – not merely statements that the service is highly available.
- PostgreSQL fidelity and exitability come next. Required extensions, logical replication, change data capture, roles, privileges, transaction behavior, and version-upgrade policies must be tested. An enterprise should also establish how a large production database could be exported or replicated to another PostgreSQL environment without an extended outage.
- Operational maturity includes connection pooling, maintenance controls, observability, patching, capacity management, diagnostic tooling, and escalation support. These operational details frequently matter more in production than benchmark leadership.
- Security and compliance should cover private connectivity, auditability, identity integration, data residency, certification scope, and encryption-key ownership.
- Full-lifecycle economics must include high-availability replicas, backup retention, cross-region recovery, data movement, network charges, operational staffing, observability, and the costs of surrounding AI and analytical services.
Evaluate Before GA, Not After It
Developers beginning greenfield PostgreSQL projects should evaluate HorizonDB now rather than waiting for general availability.
The correct preview activity is not to move a mission-critical system blindly into production. It is to test the things that will become difficult to test when a launch deadline is approaching:
Schema and SQL compatibility
Required extensions
ORM and driver behavior
Connection management
CDC and logical replication
Backup and restore
Failover behavior
Vector-search quality
Microsoft Foundry and Fabric integration
Performance under realistic concurrency
Migration out of the service
Once HorizonDB reaches general availability, business pressure may encourage teams to treat the GA label as proof that every application requirement has already been addressed. It has not. General availability indicates a vendor’s production commitment; it does not replace application-specific diligence.
Preview is the time to discover incompatibilities. GA is too late to begin asking whether they exist.
Microsoft’s Likely PostgreSQL Future
HorizonDB is likely to become Microsoft’s flagship cloud-native PostgreSQL platform for high-scale, AI-intensive and mission-critical applications. But it will coexist with other Azure database services.
Azure Database for PostgreSQL Flexible Server will remain valuable for customers who prioritize close alignment with conventional open-source PostgreSQL, established operations, and broad workload compatibility. Microsoft is also directing distributed PostgreSQL customers toward the Elastic Clusters capability of Azure Database for PostgreSQL.
One part of the earlier Azure portfolio is already changing: Azure Cosmos DB for PostgreSQL is on a retirement path and is no longer recommended for new projects. Microsoft identifies Azure Database for PostgreSQL Elastic Clusters as its forward direction for horizontally distributed PostgreSQL workloads. Cosmos DB for NoSQL, however, continues as a separate globally distributed NoSQL service for different application patterns.
The likely future Azure portfolio is therefore not one PostgreSQL service replacing every other database. It is a layered strategy:
Flexible Server for broadly compatible managed PostgreSQL
Elastic Clusters for distributed PostgreSQL
HorizonDB for Microsoft’s next-generation cloud-native PostgreSQL architecture
Cosmos DB for globally distributed NoSQL applications
The Phoenix Has the Face of an Elephant
PostgreSQL’s return is unusual because it did not rise as the proprietary triumph of one company.
Amazon adopted its interface. Google adopted its interface. Microsoft adopted its interface. EnterpriseDB industrialized it. Snowflake brought it into its AI Data Cloud. Databricks used it as the operational foundation for applications and agents.
Each vendor is trying to differentiate the storage architecture, control plane, security model, analytics connections, and AI ecosystem around PostgreSQL. Yet each is also reinforcing PostgreSQL as the common denominator.
That may be PostgreSQL’s greatest victory.
It did not defeat every rival database. It became the interface that its rivals and partners increasingly had to support.
It began as an ambitious research system, lost the first commercial and web platform rounds, survived without being tied permanently to one vendor, and waited while applications became complex enough to require the capabilities it had been designed to provide.
Now the age of agentic AI requires databases that can keep transactions, documents, metadata, permissions, search indexes, vectors, context, and history close together. It requires a database that can serve both humans and software agents without surrendering structure, governance or transactional integrity.
It requires a database that remembers.
The database that lost to MySQL and SQL Server in the 2000s is the one every major AI-era data platform is racing to rebuild, harden, and own a piece of – because it turned out to be the one database willing to remember everything, in whatever shape it arrived, forever.
The PostgreSQL phoenix has risen – and appropriately, it has the face of an elephant.