Why the Lakehouse Vendors and the Clouds Bet on Postgres for AI Applications

The lakehouse vendors and the three largest clouds have placed their bet on Postgres for AI applications, and the evidence is in the deal flow of the past twenty months. Databricks bought Neon, a serverless Postgres company, for around one billion dollars. Snowflake bought Crunchy Data, a Postgres company, for around 165 million dollars. Google announced PostgreSQL for agents in AlloyDB. Amazon embedded DuckDB into Aurora PostgreSQL so that the operational database reads Iceberg and Parquet in S3 directly. Microsoft announced HorizonDB, a new PostgreSQL-compatible service built for AI workloads.

Five vendors with five different strategies chose the same database underneath. This article explains why that happened, what the extensions did to make it possible, and which questions to ask before you commit to a Postgres offering, because the offerings are no longer the same thing. It also covers the other bet in this market, the vendors that build the same capabilities into engines of their own, such as Oracle, SAP, IBM, OceanBase, SingleStore, and TiDB, with Microsoft on both sides, because the right engine depends on the workload rather than on the choice the clouds made.

Why the Bet Landed on Postgres

The lakehouse vendors and the clouds bet on Postgres for AI applications because any vendor can build on it, most developers already know it, and the extension model let the community add vectors and analytics faster than any single vendor could. Three properties made that possible.

• The license and the governance. The PostgreSQL license is a short permissive license in the family of MIT and BSD, comparable to Apache 2.0 in what it allows. A vendor can fork the engine, add proprietary storage, sell a managed service, and owe nothing back. Just as important, no single company owns Postgres. A community runs the project, so no vendor can change the license later, as happened with Elasticsearch, MongoDB, and Redis.
• The extension model. Postgres lets anyone add index types, data types, functions, and storage behavior without touching the core. That is how vector search, columnar execution, and Iceberg access arrived. The core project stayed focused on being a relational database, and the ecosystem turned it into everything else.
• The developers. Every application team has someone who knows Postgres. When an AI application needs state, the first question is whether Postgres can hold it, and the answer is usually yes. A vendor that offers Postgres sells into a skill the customer already has.

The result is a market where the Postgres engine is shared and the platform around it is the product. Databricks sells an operational store with the same governance as the lakehouse, and the fact that it is Postgres removes the adoption barrier. The same logic holds for Snowflake, Google, Amazon, and Microsoft. The bet is not exclusive, though. Google also invests in Spanner, Microsoft in SQL Server 2025 and Fabric, Amazon in DynamoDB, and all three keep those engines as first-class options. Postgres is the engine they chose for the applications that want a relational database the whole ecosystem already speaks.

The Extensions That Turned Postgres Into an AI Database

A plain Postgres is a transactional row store. The extensions turned it into an engine that serves the three workloads an AI application needs, state, history, and retrieval, at a scale that is smaller than a dedicated system for each and large enough for most applications.

• pgvector added the vector index. It is good enough for most retrieval workloads below a hundred million vectors, and every managed Postgres on the market ships it. Similarity search over embeddings now runs in the same transaction as the business rows, with the same filters and the same security model.
• pg_lake, open sourced by Snowflake in November 2025, reads and writes Apache Iceberg tables from Postgres. The operational database reaches the lakehouse without a pipeline.
• pg_duckdb embeds the DuckDB engine for columnar execution over Postgres tables and files in object storage. Aurora’s embedded DuckDB does the same inside a managed service. Analytical scans that used to need a warehouse now run next to the transactions.
• ParadeDB adds full-text search and analytics on top of Postgres for teams that would otherwise add a search engine.

None of these extensions make Postgres the best engine for every workload. A dedicated vector database is built for billions of embeddings, and a lakehouse is built to scan petabytes of history. For the majority of AI applications, however, the workloads are small enough that one engine with the right extensions serves all three, and the consistency of one engine matters more than the extra headroom of three specialized systems.

Four Layers of Postgres Compatibility

Every offering in this market carries the Postgres label, and the label covers four different things. Postgres compatibility has four layers, the wire protocol, the SQL dialect, the extension ecosystem, and the storage engine, and the further down the layers a product goes, the more of the ecosystem works unchanged.

• The real engine. Supabase, Cloud SQL, Snowflake Postgres, and Lakebase run the actual PostgreSQL code, with the vendor’s infrastructure around it. Every extension works, every tool works, and the exit is a pg_dump.
• The query layer on another storage engine. YugabyteDB reuses the Postgres query layer on top of a distributed storage engine. The SQL dialect and most extensions work, the storage behaves differently, and distributed consistency is the reason to choose it.
• A modified engine with proprietary storage. AlloyDB and Aurora run modified Postgres with their own storage layers. Most extensions work, the storage and the replication are the vendor’s, and the exit means moving data rather than files.
• The wire protocol over a different database. CockroachDB and the PostgreSQL interface of Google Spanner speak the protocol so that drivers connect, and the engine underneath is their own. The dialect covers a subset, extensions mostly do not apply, and the reason to choose them is the engine underneath rather than the Postgres label.

All four are legitimate. The mistake is to assume that Postgres on the label means the same thing on every shortlist. The extensions you depend on today, from pgvector to pg_lake, decide which layer you need, and the layer decides what the exit will cost in three years.

What the Neon and Crunchy Data Acquisitions Tell You

The prices in the deal flow carry a message. Databricks paid around one billion dollars for Neon, a company with a serverless Postgres architecture and separated storage and compute. Snowflake paid around 165 million dollars for Crunchy Data, a company known for running the real Postgres engine well and for its work in regulated environments. Both buyers wanted an operational database that their customers’ agents could trust next to the lakehouse, and both wanted it under the same governance as the history. The premium went to compatibility plus a modern architecture, which is the combination that investors and acquirers in this market now watch. A Postgres company with a proprietary dialect would likely not have fetched the same price.

The same message shows in the product releases. Google added separate agent compute to AlloyDB that spins down when the agent finishes, plus federated queries to BigQuery, instead of building a new database for agents. Amazon took the same path and embedded DuckDB into Aurora. Vendors extend the Postgres they have rather than replace it.

Where Postgres Reaches Its Limits

Three limits show up in practice:

• Scale-out writes. A single Postgres primary has a ceiling. Beyond it, the choice is a distributed engine with Postgres compatibility such as YugabyteDB or CockroachDB, a distributed engine of its own such as OceanBase, SingleStore, or TiDB, or a different data model such as DynamoDB, each with its own trade-offs.
• Large analytical scans. pg_duckdb and the Aurora DuckDB integration serve analytical queries over operational data and files in object storage. They do not replace a lakehouse for petabyte-scale history, and the vendors that bought Postgres know it, which is why they replicate into the lakehouse rather than the other way around.
• Billions of vectors. pgvector serves most applications. At the scale where the index no longer fits the memory budget of a transactional database, a dedicated vector database earns its place.

Whether the vectors belong inside Postgres or in a dedicated vector database depends on filters, freshness of embeddings, volume, operations, and where the data already lives.

Why Oracle, SAP, IBM, and OceanBase Bet on Their Own Engines Instead

Oracle, SAP, IBM, and OceanBase made a different bet. Instead of building on Postgres, they add the same AI capabilities to engines they build and control end to end. The goal is identical on both sides, because an agent on business data needs rows, columns, and vectors in one engine and one transaction. Postgres reaches that goal with pgvector and pg_duckdb for most applications and with AlloyDB at cloud scale. The vendor engines reach it inside the systems of record that already run the business, and that bet is just as coherent.

Oracle AI Database 26ai, SQL Server 2025, SAP HANA Cloud, and IBM Db2 are the most visible examples. They serve rows, columns, and vectors inside engines their vendors have developed for decades, and MySQL HeatWave does the same for MySQL workloads. Microsoft places both bets, with HorizonDB on the Postgres side and SQL Server 2025 on its own engine.

The distributed engines take the same approach at scale. OceanBase, SingleStore, and TiDB run transactions, analytics, and vectors in one engine across many nodes, at a volume that a single Postgres primary does not reach.

The system of record in most large companies runs on one of these engines, and the AI capabilities now arrive inside it. An agent that acts on the order book inside SAP or on accounts inside the core banking system should read the data where it lives rather than through a copy in a new Postgres. Document, key-value, and graph databases such as MongoDB Atlas, Couchbase, Redis, and Neo4j add data models of their own, which Postgres handles less naturally.

The two bets meet in practice, and the choice follows the workload rather than the age of the application. A new application that fits on a single node and lives close to the lakehouse often starts on Postgres. A new application that needs global scale, very high write volumes, or the transactional guarantees of a core system often starts on Oracle, SQL Server, SAP HANA, Db2, OceanBase, SingleStore, or TiDB. An application that already runs on one of these engines gets the AI capabilities where it runs, without a migration. A comparison of OceanBase, Databricks, and Snowflake for transactional workloads, analytics, and AI agents shows how the two bets play out in practice.

Four Questions Before You Commit to a Postgres Offering

The four layers and the limits above lead to four questions that separate the Postgres offerings on a shortlist. Ask them before the demo, because the answers decide the architecture and the exit cost for the next three years.

• Which layer of compatibility do you get? The real engine, the Postgres query layer on another storage engine, a modified engine with the vendor’s storage, or only the wire protocol. Ask for the list of supported extensions and compare it with the ones your application uses today. A missing extension on that list is the earliest warning you will get.
• Where does the analytical path go? Some offerings replicate into a lakehouse, some embed an analytical engine such as DuckDB, and some have no analytical path and leave it to you. If it is replication, ask for the typical lag window, because an agent that reads history and state in one request has to tolerate it.
• Where do the vectors live? Either in pgvector inside the same transaction as the business rows, or in a separate vector service with a pipeline between them. The first keeps embeddings fresh and filters simple, the second scales further and adds a second system to run.
• What does the exit cost? With the real engine it is a pg_dump, with a modified engine a data migration, with the wire protocol an application rewrite. The answer follows from the first question, so check the two against each other.

The lakehouse vendors and the clouds bet on Postgres because it removed the adoption barrier for everyone who builds on it. The decision that remains for you is which Postgres, or whether your workload belongs on an engine of the vendor’s own, and that decision deserves the same care that choosing a database always did.

The Data Streaming Landscape covers the event streaming platforms that connect these databases, and the Trusted Agentic AI Landscape covers the models and agent frameworks on top of them.

Stay up to date with the newsletter and connect on LinkedIn.