Competition is good. It focuses your energies. It keeps you sharp and pushes you to be better. At Cockroach Labs we welcome competition. It hasn't escaped our notice that a new entrant in the database landscape is frequently comparing themselves against us, making claims about their performance and functionality vis-a-vis our own. We decided to take a closer look. This is our analysis of CockroachDB vs. Yugabyte v2.0.0. All benchmark comparisons were done with CockroachDB v19.2.0.
TLDR: CockroachDB vs Yugabyte
- On Yugabyte's custom benchmark we discovered an apples to oranges performance comparison due to the behavior of the benchmark and Yugabyte's choice to use hash partitioning by default. We unpack why using hash partitioning by default is a dubious choice for a SQL database. After adjusting for these discoveries, CockroachDB outperforms Yugabyte on all of the workloads.
- On Sysbench we discovered problems in Yugabyte with schema changes and batching. The schema change problems are architectural and will be challenging to solve. The performance problems with batching look to be solvable with a bit of elbow grease.
- On Sysbench we discovered that Yugabyte returns transaction retry errors in situations that neither PostgreSQL or CockroachDB do. These transaction retry errors cause Sysbench to fail to complete on several workloads. We were only able to gather results for Yugabyte on 4 of the 9 Sysbench workloads. CockroachDB can successfully complete all 9 workloads.
- On YCSB we compared Yugabyte's SQL performance to CockroachDB and showed CockroachDB performance is better across all workloads.
- We discovered that Yugabyte SQL tables have a maximum of 50 tablets.
- We discovered that Yugabyte tablets do not split or merge which requires the operator to make an important upfront decision on their data schema.
- We discovered that a Yugabyte range partitioned table is limited to a single tablet which limits the performance and scalability of such tables.
- We discovered differences between CockroachDB's distributed SQL execution which decomposes SQL queries in order to run them close to data, and Yugabyte's SQL execution which moves data to a gateway node for centralized processing.
- We discovered that without application-level coordination Yugabyte schema changes can easily lead to data inconsistencies.