Another NewSQL Contender
TiDB (Titanium DB) is a popular open-source NewSQL database created by PingCAP. It is particularly widely adopted in Asia and is designed to be a drop-in replacement for MySQL — it speaks the MySQL wire protocol, so existing MySQL applications can often connect to TiDB with no code changes.
TiDB takes a different architectural approach from CockroachDB: rather than building a monolithic distributed database, it cleanly separates concerns into distinct layers that can be scaled independently.
The Three-Layer Architecture
Layer 1: TiDB Server (Stateless Compute)
The TiDB Server layer handles SQL parsing, query planning, and query execution coordination. Critically, it is stateless — it stores no data. This means you can add or remove TiDB Server nodes freely based on query load without affecting data storage. A load balancer distributes incoming connections across TiDB Server nodes.
Layer 2: TiKV (Distributed Storage)
TiKV is a distributed, transactional key-value store that actually holds the data. It shards data into regions (similar to CockroachDB's ranges) and replicates each region using the Raft consensus algorithm. TiKV provides ACID transactions using a two-phase commit protocol inspired by Google's Percolator paper.
Layer 3: PD (Placement Driver)
The Placement Driver is TiDB's cluster brain. It stores metadata about which regions live on which TiKV nodes, handles leader election for Raft groups, and makes scheduling decisions — for example, moving regions to balance load or rebalancing after a node failure. It uses etcd internally for its own high availability.
Client → [Load Balancer] → [TiDB Server 1] [TiDB Server 2] [TiDB Server 3]
↓ ↓ ↓
[PD Cluster (etcd-backed)]
↓
[TiKV Node 1] [TiKV Node 2] [TiKV Node 3]
(Region A) (Region B) (Region C)
(Region D replica) ...
TiFlash: Analytical Queries
TiDB also includes TiFlash, a columnar storage engine that replicates data from TiKV in a column-oriented format. This allows TiDB to serve both OLTP (transactional) and OLAP (analytical) workloads from the same database — a pattern called HTAP (Hybrid Transactional/Analytical Processing). TiFlash replicas are kept in sync via Raft, so analytical queries always read fresh data.
Key Point: TiDB's compute-storage separation enables independent scaling of query processing and data storage. Its MySQL compatibility lowers the migration barrier significantly, and TiFlash enables HTAP workloads without maintaining a separate analytical database.