PostgreSQL is 30 years old, open source and owned by no one. So why have the biggest data platform companies spent more than a billion dollars since mid-2025 trying to own a piece of it?
The shopping list is long. Databricks bought Neon for roughly $1 billion in May 2025 and turned it into Lakebase, its serverless Postgres service. Within weeks, Snowflake bought Crunchy Data for about $250 million, which became Snowflake Postgres. In August, Databricks added ElectricSQL to push Postgres out to the edge, where AI agents actually run. And just last week, TiDB announced Postgres support in public preview.
Postgres has become the most fought-over real estate in the data stack. Data leaders should understand why, because the answer says a lot about where lock-in is heading next.
They're not buying a database. They're buying gravity.
None of these vendors needed to invent a better Postgres. The engine inside Lakebase is still Postgres. What changes is everything around it. One independent analysis put it plainly: Lakebase doesn't change the database, it changes the owner, and what you're really buying is the Databricks catalog, billing account and roadmap.
That's the strategy. Postgres is where developers already are, where AI applications keep their state, and where agents increasingly read and write. If a platform can own the operational database too, it can pull those workloads, and their compute spend, into the same bill as the warehouse and the lakehouse.
That can be genuinely convenient. It's also a quiet shift: from a database you can run anywhere, to a database tied to one vendor's platform.
Three distinctions worth keeping straight
1. Postgres-owned is not the same as Postgres-compatible. A vendor-managed Postgres service gives you the Postgres engine on that vendor's infrastructure, under their pricing and roadmap. Postgres compatibility means the SQL, drivers, tools and skills your team already has keep working, wherever the platform runs. The first is a product. The second is a portable asset.
2. Transactions and analytics are different jobs. Lakebase and Snowflake Postgres are aimed mainly at operational workloads: application state, agent memory, transactional data. Large-scale analytics, with hundreds of concurrent users hitting billions of rows, still needs a massively parallel engine. Don't let a Postgres label blur those two requirements in your architecture review.
3. The dialect is the durable part. Platforms come and go. Contracts get renegotiated. The SQL your analysts write and the integrations your engineers build are what you live with for a decade. Keeping that layer on a widely adopted, open standard is the cheapest insurance in the stack.
Questions to ask before you consolidate Postgres onto a platform
- Can we run the same workloads outside this vendor's cloud, or in our own data center, without a rewrite?
- Are we paying for Postgres separately, or is it bundled in a way that makes the true cost hard to see?
- Which features are open-source Postgres, and which are proprietary extensions we'd lose if we left?
- Does putting operational and analytical data under one vendor raise our concentration risk?
Where Yellowbrick fits
Yellowbrick took the compatibility path from the start. It's a massively parallel SQL data warehouse that stays compatible with the broader PostgreSQL ecosystem, and it runs as software in your own environment: AWS, Azure, Google Cloud, your data center, or the Yellowbrick Andromeda appliance.
In practice, that means:
- Your Postgres skills transfer. Analysts and engineers work in familiar SQL, with familiar tools and drivers, instead of learning a proprietary dialect.
- Analytics at MPP scale. Yellowbrick is built for the job vendor Postgres services aren't: high-concurrency, petabyte-scale analytics with strict SLAs.
- Migration without a rewrite. Customers have modernized Netezza and similar legacy platforms without extensive SQL rewrites.
- No new landlord. Because Yellowbrick runs in your accounts and data centers, adopting it doesn't move your data or your bill into someone else's platform.
The takeaway
The Postgres land grab is a sign of how valuable an open standard becomes once enough people depend on it. Vendors want to own it because owning it means owning the workloads built on top.
You don't have to let them. Pick platforms that speak Postgres without making you rent it, and your SQL, your skills and your options stay yours.
Curious how Yellowbrick's PostgreSQL compatibility would map to your current workloads? Book a session with our team.