Why Postgres Is Winning: The $1B Acquisition Wave

In the span of about a month in 2025, two of the biggest names in data infrastructure went Postgres shopping. Databricks bought the serverless-Postgres company Neon for roughly a billion dollars. Snowflake bought Crunchy Data. Around the same time, Timescale rebranded itself to TigerData to signal it’s now a general-purpose Postgres platform, not a time-series niche. Put those moves next to a developer survey that keeps crowning Postgres the most-used and most-admired database, and a real question emerges — one worth answering with specifics rather than vibes. This is why Postgres is winning: not because it added a killer feature, but because of a structure that keeps compounding.

That structure has four parts: an acquisition wave that reveals where the industry thinks the future is, a governance model no single company controls, a license that can’t be weaponized, and an extension ecosystem that grows faster than any one vendor could build. Let’s take them in turn.

Postgres at the center of the data industry as hyperscalers gather around it — the ecosystem behind why Postgres is winning

💰 The Acquisition Wave: Follow the Money

Start with the deals, because money is an honest signal. Databricks’ acquisition of Neon closed in May 2025 for a reported ~$1 billion, explicitly to give Databricks a Postgres-compatible transactional layer for AI-agent workloads. Databricks has since said Neon’s database count grew from about 6,000 to over 700,000 in the year after the deal, with storage pricing cut 80% — impressive numbers, and worth noting they’re the acquirer’s own.

Snowflake bought Crunchy Data in June 2025 to build “Snowflake Postgres.” Here the reported price needs care: public reporting put it around $250 million, while Snowflake’s own SEC filing lists $164.5 million in cash. Those two figures don’t reconcile cleanly, so the honest move is to cite both with their sources rather than pick one. And Timescale became TigerData on June 17, 2025 — a rebrand reflecting that most workloads on its platform are no longer time-series-specific. The company reports 2,000+ customers and mid-eight-figure ARR growing over 100% year over year; again, its own figures, and the open-source TimescaleDB extension continues unchanged.

Not everyone consolidated — Supabase remains independent, positioned as an open-source Firebase alternative on a dedicated Postgres. And one cautionary data point: Tembo, once cited as a managed-Postgres option, shut that business down in May 2025 to pivot into AI coding-agent tooling. This space turns over fast; treat any “who owns what” list, including this one, as a snapshot.

The pattern underneath the deals is the real story. Databricks and Snowflake — companies whose core engines aren’t Postgres — both bet on Postgres compatibility as the front door for AI-native data platforms. That’s a bigger claim than “Postgres is popular.” It’s “Postgres compatibility is becoming table stakes.”

The Postgres acquisition wave — large data companies absorbing serverless-Postgres startups like Neon and Crunchy Data

🏛️ Nobody Owns It (And That’s the Point)

Here’s what makes those acquisitions possible without anyone “buying Postgres”: no one can. The project is run by the PostgreSQL Global Development Group. A seven-person, all-volunteer Core Team coordinates releases, infrastructure, and the rare consensus-breaking call — but deliberately stays out of technical direction, which happens in the open on the pgsql-hackers mailing list. There are no GitHub pull requests; patches are proposed and reviewed by email, then tracked through periodic “CommitFests.” It’s higher-friction than the GitHub-native workflow most engineers know, and that friction is exactly the point.

Why does this matter when you’re choosing infrastructure? Because the useful question about a dependency isn’t “how many stars does it have” — it’s “what happens when a company wants something the community doesn’t?” Postgres has a 25-plus-year track record answering that: essentially zero governance-driven forks and zero license flips. A company can acquire a Postgres business; it cannot acquire the project’s steering wheel, because there isn’t one to buy.

Postgres governance as a circle of volunteer contributors stewarding a shared project with no single corporate owner

📜 The License Clause Under Everything

The load-bearing wall beneath all of this is the PostgreSQL License: a short, OSI-approved, BSD/MIT-style permissive license — commercial use with no fee, no copyleft obligation beyond preserving the notice — and the Global Development Group has stated there are “no plans” to ever change it. Because no single entity holds the pen, there’s simply no license to weaponize.

That’s not an abstract virtue. Compare it to the cautionary tales. MongoDB relicensed its server to the Server Side Public License in 2018 — a license the OSI has never approved — specifically to stop cloud providers from offering it as an unpaid managed service. Elastic did something messier: it moved Elasticsearch from Apache 2.0 to a dual SSPL/Elastic License in 2021 to block AWS, then partially reversed course in 2024 by adding AGPLv3 as a third option. MySQL’s case is subtler still — it’s GPL, but Oracle controls the roadmap and sells commercial licenses, so one company has the final say. Postgres never faced any of these forks because no company was ever positioned to force the choice. If you’re picking a database for something you intend to still control in five years, that’s a license-clause argument, not a popularity one.

The permissive PostgreSQL License as a keystone holding up an entire ecosystem of companies and extensions

🧩 The Extension Explosion (The Real Moat)

Postgres’s other superpower is that it was built to be extended, and the community has run with it far past PostGIS and pgvector. A quick tour of what’s current: pgvectorscale adds a disk-based ANN index (its maker benchmarks it at 243% faster than Weaviate at 99% recall on a million-embedding set — a vendor benchmark, so directional). Citus brings distributed sharding and, now Microsoft-owned, powers Azure Cosmos DB for PostgreSQL. pgmq is a message queue; pg_cron a scheduler; Apache AGE an Apache-project graph extension speaking openCypher; ParadeDB’s pg_search brings Elasticsearch-grade BM25 full-text search via a Rust engine, with pg_analytics adding columnar analytics.

The public registry (PGXN) lists roughly 375–390 extensions — but that’s a floor, not a census: PostGIS, one of the most-deployed extensions in existence, was never even listed there, and community estimates of the real ecosystem run into four figures. The mechanism behind all of it is a stable, decades-old extension API, which is why capabilities can arrive as fast as people can write them, with no vendor roadmap gating the queue.

One piece of due diligence, though: an open extension API doesn’t mean every extension carries core Postgres’s governance guarantees. Single-vendor extensions move fast but can be abandoned or relicensed if the company pivots — Tembo’s Trunk registry shutdown is the reminder. Check who maintains it before you put it in a production path.

The Postgres extension ecosystem — modular capabilities (vector, geospatial, graph, queue, search) docking onto one engine

📊 The Numbers, Kept Honest

Two data sources get quoted constantly, and they measure different things. In Stack Overflow’s 2025 Developer Survey, Postgres was used by 55.6% of all respondents (58.2% of professional developers, up from 48.7% the year before — the largest single-year jump in its survey history), rated most admired at roughly 65%, and most desired at roughly 46%. Sources disagree on whether that’s its third or fourth consecutive year sweeping all three, so it’s worth checking the streak against Stack Overflow’s own results page before quoting a number.

Separately, DB-Engines — which scores raw market footprint (mentions, job postings, discussion volume) rather than developer sentiment — still ranks Oracle, MySQL, and SQL Server above Postgres at #4, even as Postgres posted the largest score gain of any system in the first half of 2026. Both things are true; don’t blend them into a single “Postgres is #1” soundbite, because they’re different instruments. And “no company owns Postgres” doesn’t mean no company matters — EDB, TigerData, Crunchy Data, and Supabase all fund substantial full-time engineering. The claim is narrower and more interesting: no single one of them can change the license, roadmap, or trademarks alone.

🚪 The “Just Use Postgres” Argument

You’ve probably seen the phrase. Stephan Schmidt’s essay “Just Use Postgres for Everything” is its most-cited source, arguing that Postgres extensions and features can replace Kafka, RabbitMQ, Redis, and even MongoDB for a large share of startup workloads — trading a little specialized power for a lot less operational surface area. It’s a genuine engineering position with genuine critics: the trade-off gets real at high scale or when you need a specialized guarantee (Kafka’s log-compaction semantics, a dedicated vector database’s recall/latency curve). Cite it as a documented position, not settled consensus — which is exactly how its own advocates frame it.

🤝 How to Actually Plug In

If this makes you want to get involved, the on-ramp is specific, not vague. Technical direction lives on the pgsql-hackers mailing list; patches go through CommitFests. The flagship in-person events are PGConf.dev (Vancouver, May 2026) and PGConf.EU (Valencia, October 2026), with POSETTE as a free online option and regional PGDays running year-round. There’s an active Slack workspace and Discord servers, including one dedicated to core-development discussion. “Join the community” turns out to be a set of concrete front doors.

🧭 What This Means for You

Read the acquisition wave as a strategic signal: Postgres compatibility is becoming the default interface for AI-native data platforms, which is a reason to weigh “Postgres-compatible but not actually Postgres” engines carefully in an architecture decision. Read the governance and license as a safety argument for building on Postgres long-term. And read the extension explosion as room to grow without re-platforming. None of these is the reason Postgres is winning — together they are. A permissive license no one can flip, a governance model no one can buy, and an extension API anyone can build on compound into something a single well-funded competitor can’t easily replicate: an ecosystem that gets more valuable the more people bet on it.

📚 Further Reading

Why Postgres Became the Default Database for AI Apps — the technical companion to this industry view.
Is Postgres a Real Vector Database? — a close look at one of the extensions driving the wave.
Postgres as Your Entire AI Backend — the “just use Postgres” argument made concrete.
Primary sources: PostgreSQL project governance and license, and the DB-Engines ranking trend.

❓ Frequently Asked Questions

Who owns PostgreSQL?

No single company. It’s run by the PostgreSQL Global Development Group, with a volunteer Core Team coordinating releases and technical direction happening openly on the pgsql-hackers mailing list. Companies like EDB, TigerData, Crunchy Data, and Supabase contribute heavily, but none controls the license, roadmap, or trademarks alone.

Why are Databricks and Snowflake buying Postgres companies?

Both bet that Postgres wire-protocol compatibility is becoming the default “front door” for AI-native data platforms. Databricks acquired Neon (~$1B, 2025) and Snowflake acquired Crunchy Data (2025) to add a Postgres-compatible transactional layer — even though their core engines aren’t Postgres. It signals that Postgres compatibility is becoming table stakes.

Is Postgres actually the most popular database?

It depends on what you measure. Stack Overflow’s 2025 survey ranks it #1 in developer usage (55.6%), admiration, and desire. DB-Engines, which scores market footprint, still puts Oracle, MySQL, and SQL Server ahead at #4 — though Postgres is the fastest-growing of them. Both are true; they measure different things.

Could Postgres ever pull an “SSPL rug pull” like MongoDB or Elastic?

Structurally, no single party can. Its permissive, OSI-approved license has no copyleft to weaponize, and no company holds the pen, so there’s no owner positioned to relicense it. That’s the specific structural difference from MongoDB’s SSPL move or Elastic’s 2021 relicense.

What makes the extension ecosystem so important?

A stable, decades-old extension API lets the community add major capabilities — vector search, geospatial, graph, queues, columnar analytics — without forking Postgres or waiting on a vendor roadmap. That’s the real moat: capabilities arrive as fast as people can build them, and no single company gates the queue.

📚 Recommended Resources

Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.