White Paper: Just-in-Time Database Access Best Practices

Comparison

TiDB vs. CockroachDB: the Distributed Clash between MySQL and PostgreSQL

Tianzhou
Tianzhou3 min read
TiDB vs. CockroachDB: the Distributed Clash between MySQL and PostgreSQL

This is a series of articles between MySQL and PostgreSQL:

TiDB and CockroachDB are the two most popular distributed database solutions (NewSQL) in their respective ecosystems. While teams rarely choose a distributed database on day one, understanding these options becomes crucial when scalability challenges arise.

Why Compare TiDB and CockroachDB

  1. As a responsible architect, it's essential to understand the entire ecosystem before making initial database choices that may impact future scalability options.

  2. When teams eventually consider distributed databases, scalability is typically the primary concern, with cost as a secondary factor. If a solution can effectively address these challenges, other obstacles—including switching database dialects—can be overcome.

Below we compare between TiDB and CockroachDB from the following dimensions:

License

TiDB is licensed under Apache License 2.0. Its internal storage engine TiKV, which has been donated to CNCF, is also under Apache License 2.0.

CockroachDB switched to an Enterprise license in 2024, generating backlash in the community (1, 2). Its storage engine Pebble uses BSD-3-Clause License.

Compatibility

Both products advertise compatibility with their vanilla counterparts (MySQL for TiDB, PostgreSQL for CockroachDB), but this primarily refers to wire-protocol compatibility rather than full feature parity:

Architecture

TiDB uses a modular architecture with separation between components:

  • SQL layer written in Go
  • Storage engine (TiKV) written in Rust
  • Clear division between compute and storage components

tidb-arch

On the other hand, CockroachDB employs a more unified approach:

  • Both SQL layer and storage engine (Pebble) written in Go
  • Each node bundles SQL processing and storage functionality
  • More integrated design philosophy

cockroachdb-arch

Another critical architectural difference is in timestamp generation for transaction management:

  • TiDB uses a dedicated timestamp allocator (Placement Driver)
  • CockroachDB relies on NTP (Network Time Protocol)

Scalability

The architectural differences lead to different scalability characteristics:

TiDB:

  • Independent scaling of compute (TiDB) and storage (TiKV) layers
  • More flexible for workloads with uneven compute/storage demands
  • May require more configuration tuning for optimal performance
  • Better suited for read-heavy workloads and analytical queries at scale (via TiFlash)

CockroachDB:

  • Simpler "add more nodes" scaling model
  • More consistent performance across different scales
  • Generally easier initial setup and maintenance
  • Typically performs better for write-intensive workloads

Neither system is universally "better" for all use cases. You have to extensively test your particular workload patterns.

Summary

This concludes our MySQL vs. PostgreSQL series. When reaching the distributed database level, the original SQL dialect becomes less relevant than the scalability and operational characteristics of the distributed system. Both TiDB and CockroachDB offer compelling solutions for scaling beyond traditional single-node databases, but with different approaches and trade-offs.

The choice between TiDB and CockroachDB should be driven primarily by your specific scaling needs, workload patterns, and operational preferences rather than strict adherence to the MySQL or PostgreSQL ecosystem.

For teams at this crossroads, it's worth investing time in proof-of-concept testing with both systems using representative workloads before making a final decision.

Of course, needing a distributed database solution is a good problem to have – it means you've grown beyond what conventional databases can handle.

Related posts

Back to blog