Databases in 2025: A Year in Review
Andy Pavlo's annual retrospective on the database industry: PostgreSQL acquisitions totalling over a billion dollars, MCP replacing vector indexes as the year's checkbox feature, and a file format war that finally put pressure on Parquet.
PostgreSQL v18 added async I/O and skip scans — features other databases had for two decades. So why did the two largest data platforms on earth each spend hundreds of millions of dollars acquiring PostgreSQL companies in the same summer?
Source
Databases in 2025: A Year in Review
By: Andy Pavlo, Carnegie Mellon University
Published: Jan 04 2026
Type: Engineering article
Pavlo has written these annual retrospectives since 2021, and each one is the most reliable map of where the industry’s energy actually went versus where trade press said it was going. This edition covers a year that felt chaotic from inside it but reads clearly from outside: database engines have commoditised, and the real competition moved to the ecosystem layer.
The year databases became infrastructure fights
PostgreSQL v18, released in November 2025, finally added asynchronous I/O — meaning the engine no longer blocks waiting for the OS to schedule each disk read before continuing. Every other major database abandoned reliance on the OS page cache years ago; PostgreSQL was the last holdout. It also shipped skip scans, letting the query planner use a multi-column B-tree index even when the leading column is absent from the query, a capability Oracle has had since version 9i in 2002. Judged by features alone, PostgreSQL v18 looks like a slow student catching up.
That framing misses what actually happened in 2025. The year’s most significant database story wasn’t a feature; it was a string of acquisitions that tell you where the money thinks the value is. Databricks, the data platform that raised $5 billion across two rounds in 2025 alone, paid $1 billion for Neon — a serverless PostgreSQL company that made database branching a first-class operation so that agents can test schema changes without touching production. Snowflake paid $250 million for CrunchyData, a 13-year-old PostgreSQL services company that had quietly accumulated top-tier kernel contributors. Microsoft, which bought the Citus sharding extension in 2019, launched HorizonDB — a compute-storage separated PostgreSQL service following the same architecture Amazon Aurora pioneered in the 2010s. Every major cloud-native data platform now runs its own PostgreSQL offering; every major cloud vendor has had one for years. The acquisition spree isn’t a bet on PostgreSQL’s code quality. It’s a bet on the network effect: talent concentration, developer familiarity, and tooling investment are self-reinforcing at a scale that no competing engine can match.
The horizontal scaling gap in PostgreSQL is also finally seeing serious commercial investment. Supabase hired Sugu, the Vitess co-creator and PlanetScale co-founder, to lead Multigres — sharding middleware modeled on how Vitess shards MySQL. PlanetScale responded with Neki. PgDog entered the same space. None of these are the first attempts at distributed PostgreSQL — Greenplum, Citus, and Postgres-XC all predated them — but the fact that well-funded companies are running three concurrent projects suggests the problem has graduated from “academically interesting” to “commercially necessary.” YugabyteDB has the widest real-world deployment among sharded PostgreSQL systems but remains a hard fork, compatible only with PostgreSQL v15. Aurora Limitless exists but is closed source. The open alternatives are new, and it will take a few years to know which one wins.
If 2023 was the year every database added a vector index, 2025 was the year every database added an MCP server. Anthropic published the Model Context Protocol in November 2024; OpenAI adopting it in March 2025 turned it into the de facto standard for exposing databases to LLMs. Within months, every category of database — OLAP systems like ClickHouse and Snowflake, SQL systems like Oracle and PlanetScale, NoSQL systems like MongoDB and Redis — had shipped an MCP server. The pattern is familiar. A new access channel arrives from the AI ecosystem, and the database industry treats adoption as a checkbox. What’s actually interesting is the secondary effect: database branching became a competitive differentiator for agentic workflows, because agents need to test changes in isolation before touching production state. Neon reported in July 2025 that agents were responsible for creating 80% of new databases on the platform. Systems that designed branching in from the start have a structural advantage over those adding it afterward.
The file format market, dormant since Parquet’s consolidation around 2012, produced five new open-source columnar formats in 2025: CWI FastLanes, CMU and Tsinghua’s F3, SpiralDB’s Vortex, AnyBlox (VLDB Best Paper winner), and Microsoft’s Amudai — which was quietly killed or closed-sourced by year-end. The core problem isn’t Parquet’s specification, which can and has evolved; it’s the fragmentation across library implementations. Pavlo’s own analysis of Parquet files in production found 94% of them use only v1 features from 2013, even when their timestamps are after 2020. Libraries in different languages support different subsets, so every writer defaults to the lowest common denominator to ensure any reader can open the file. F3, which Pavlo co-developed with researchers at Tsinghua, Wes McKinney, and CMU, attacks this differently: new encodings ship with embedded WASM decoders inside the file, so any reader that doesn’t have native support can still decode via the WASM fallback. AnyBlox takes the same idea further, generating a single WASM program to decode the entire file. SpiralDB’s Vortex made the most organisational noise by donating to the Linux Foundation and forming a multi-organisation steering committee. Nobody expects Parquet to disappear, but the field is for the first time genuinely contested.
Two late-cycle acquisitions point toward a trend worth watching. Couchbase and SingleStore both went to private equity in 2025. Before 2020, Pavlo can find only two PE acquisitions of database companies. Since then there have been five. The pattern suggests a class of database companies — too slow-growing for venture returns, no clean path to a strategic acquirer — that can still sustain a PE hold on maintenance revenue. Expect more of this as vector database hype fades and a long tail of specialised systems look for exits that don’t involve an IPO or a billion-dollar strategic acquirer.
My take
What this retrospective reveals is that “database company” has split into two distinct businesses. The first is managed infrastructure that cloud platforms compete for — PostgreSQL is the reference architecture, and the fight is over developer experience, branching, and AI integration. The second is the engine itself, which has commoditised to the point where performance differences between modern systems are mostly irrelevant for common workloads. GPU-accelerated databases have chased the engine market for a decade and keep failing commercially. The Voltron Data failure and the HeavyDB acquihire by Nvidia both fit that pattern. The real action is in the first market, and it looks much more like a platform fight than a database fight.
Where this is useful
- When choosing a managed PostgreSQL provider for new projects: the Neon/HorizonDB/Supabase landscape is reshaping quickly, and branching support matters if agents will touch the database.
- When wiring an MCP server in front of a database: Pavlo’s warning about unfettered access applies — read-only mode, row limits, and query timeouts at the proxy layer, not in documentation.
- When picking a columnar file format for a new analytics pipeline: this is the moment to evaluate the new formats rather than defaulting to Parquet without checking maturity.
- Less relevant for teams running on-premises OLTP workloads where cloud DBaaS positioning doesn’t affect day-to-day engineering decisions.
Apply this: If you’re building database access via MCP for an agent, treat the MCP server as an untrusted client — enforce read-only mode, cap result set sizes, and add query timeouts at the connection layer.
What I want to remember
Remember: PostgreSQL’s dominance in 2025 is an ecosystem story, not a code quality story. The features are years behind; the talent concentration, network effects, and acquisition currency are far ahead of any alternative.