YugabyteDB and CockroachDB: distributed databases in 2025
Actualizado: 2026-05-03
In 2025, talking about distributed SQL is no longer talking about promises. YugabyteDB and CockroachDB are two mature engines, in production at large companies, with years of mileage and active communities. For teams designing new platforms, choosing between one of them or sticking with traditional Postgres is a frequent and non-trivial decision.
Key takeaways
- Vertical PostgreSQL covers 90% of cases: switching to distributed SQL for trend reasons has real cost in latency, operations, and SQL compatibility.
- YugabyteDB literally reuses PostgreSQL’s query processor; CockroachDB reimplements SQL from scratch — the compatibility gap is significant.
- CockroachDB changed to a proprietary license in 2024; YugabyteDB keeps Apache 2.0 for the community edition — this has been Yugabyte’s most important growth factor in the last year.
- On replicated writes across three nodes in a single region, both deliver tens of thousands of ops/s per node at 2 to 10 ms latency — clearly worse than single-machine Postgres.
- The three cases with clear sense for distributed databases are: simultaneous multi-region writes, volume beyond vertical scale, and fault tolerance without human intervention critical.
The problem they both solve
Vertical PostgreSQL has for years been the most efficient answer to most relational database needs. It runs on one machine, usually has a read replica, and scales vertically by adding cores or disk. This architecture covers ninety percent of cases, but it has a clear ceiling: one physical machine, one server as the failure point for writes, and one geographic region as base latency.
When an application needs to go beyond, classic options — manual partitioning, application-level sharding, read-only replicas with consistency trade-offs — introduce operational complexity the team ends up paying for years. Both databases promise the same at a high level: compatible SQL, ACID distributed transactions, synchronous replication across nodes, fault tolerance without manual intervention, and horizontal scaling by adding nodes. The difference is in how they deliver it.
Architectures starting from different places
CockroachDB, created by Cockroach Labs and released in 2015, starts from a design inspired by Google Spanner. Its storage layer is in Go, with RocksDB and now its own Pebble engine. Each table is automatically split into row ranges, each range is replicated via Raft across three nodes by default, and distributed transactions use a protocol based on synchronized clocks. Its SQL dialect is compatible with the PostgreSQL wire protocol, but the implementation is its own.
YugabyteDB, created by former Facebook engineers and open-sourced in 2019, takes a different road. It has a storage layer called DocDB based on RocksDB with Raft replication per tablet, but on top it reuses the PostgreSQL query processor. This is key: YugabyteDB’s SQL layer is literally modified Postgres code. That means most extensions, functions, stored procedures, and specific behaviors work the same as in Postgres.
This difference has big practical consequences. In CockroachDB, every Postgres feature you need has to be reimplemented by the Cockroach Labs team. They have been closing the gap for years, but extensions like PostGIS with all its functions, timescaledb, pg_trgm, or subtle behaviors like certain partial index types are still missing. In YugabyteDB those things work or have a much smaller gap because they leverage Postgres code directly.
Performance and latency
Performance on these databases is very workload-dependent. On simple writes replicated across three nodes within a region, both perform in the tens of thousands of operations per second per node, with typical latencies between two and ten milliseconds. This is significantly worse than undistributed Postgres on a single machine, which can deliver hundreds of thousands of writes per second with sub-millisecond latency.
The cost of distribution is real and has to be accepted. Where these databases shine is when you need to survive failures, spread load across regions, or scale beyond what a single machine delivers. Both allow serving reads from the replica closest to the client and optionally permit bounded-staleness reads to trade latency for a small lag.
SQL compatibility in practice
For an application already using Postgres, the critical question is how much code needs rewriting. YugabyteDB has an advantage from its reuse of Postgres parser and executor: most schemas, queries, and procedures work unchanged, though there are trade-offs on index types and some locking functions.
CockroachDB has done enormous work getting its dialect close to Postgres, but differences remain that can bite: certain complex JOINs behave differently, some aggregate functions are missing, and stored procedures arrived late. Both support the Postgres wire protocol and standard drivers and migration tools work.
Licenses and business model
Here the comparison gets interesting. CockroachDB changed in 2024 from BSL to a proprietary license, eliminating the free option for enterprise use. YugabyteDB keeps its Apache 2.0 license with no restrictions for the community edition, which includes most features.
This difference clearly pushes teams that value a pure open license toward YugabyteDB, and has probably been the most important growth factor for the project in the last year. Both offer managed services in the cloud (YugabyteDB Aeon, CockroachDB Cloud) and work well on Kubernetes with official operators.
When a distributed database pays off
My reading after seeing several deployments is that these databases are a real solution to real problems, but are often adopted prematurely. Postgres on a well-sized machine solves the problem for most companies for many years. Switching to distributed SQL just because it sounds modern is trading a problem you do not have for three you will have: more complex operation, worse latency, and SQL trade-offs that are not obvious from outside.
The cases where migration has clear sense are three:
- Multi-region needs with writes from several regions at the same time
- Volumes that have outgrown what a single machine delivers, once vertical scale and application-level partitioning have been exhausted
- Continuity requirements where fault tolerance without human intervention is critical
How to think about choosing between the two
If the decision is between YugabyteDB and CockroachDB, in 2025 I lean toward YugabyteDB for most cases, for four reasons: deeper Postgres compatibility, firm open license, ecosystem closer to the mainstream Postgres world, and features previously missing now closed. CockroachDB remains a solid option if your application is already written against its dialect or if your case fits well with its cloud serverless model.
Beyond that comparison, it is worth remembering that Neon, Supabase, and Crunchy Bridge have advanced a lot in offering serverless Postgres with multi-zone replication without jumping to full distributed SQL. For many cases that used to push toward Yugabyte or Cockroach, managed Postgres with well-designed geographic replicas is now enough. The “distributed database yes or no” question today has an intermediate nuance it did not have in 2020.
