TiDB Overview: NewSQL Features, Architecture, Compatibility, and Application Scenarios

What is NewSQL

NewSQL combines the scalability of NoSQL with the relational model and strong ACID guarantees of traditional SQL databases, offering horizontal elasticity and cloud‑native distributed architectures.

Problems of Traditional SQL

As internet services grew, monolithic relational databases hit performance ceilings, leading to two common mitigation strategies: upgrading hardware and sharding data across distributed clusters, each introducing new complexities.

Issues with NoSQL

NoSQL prioritizes high availability and scalability but sacrifices strong consistency and SQL compatibility, making it unsuitable for many enterprise scenarios that require ACID transactions.

NewSQL Characteristics

SQL support with complex queries and analytics.

Full ACID transaction guarantees.

Elastic scaling transparent to applications.

High availability with automatic failover.

TiDB: From Idea to Product

TiDB was inspired by Google’s F1/Spanner papers and was created by PingCAP’s co‑founder Huang Dongxu in 2012 to provide a distributed relational database that scales horizontally while remaining MySQL‑compatible.

Community vs Enterprise Editions

TiDB offers a free community edition and a paid enterprise edition that adds professional support and advanced security features.

Core Features of TiDB

Horizontal elastic scaling – add nodes to increase capacity.

Distributed transaction support – 100% ACID compliance.

Financial‑grade high availability via Raft consensus.

Real‑time HTAP – simultaneous OLTP and OLAP processing using TiKV (row store) and TiFlash (column store).

Cloud‑native design – deep integration with Kubernetes for public, private, and hybrid clouds.

Full MySQL 5.7 protocol compatibility.

TiDB Components

TiDB Server

Stateless SQL processing layer that receives queries, plans execution, and interacts with storage via PD.

Placement Driver (PD) Server

Manages metadata, schedules region placement, and allocates global transaction IDs; runs a Raft cluster for fault tolerance.

TiKV Server

Distributed key‑value store that holds data in regions, replicates via Raft, and balances load under PD’s direction.

TiSpark

Integrates Spark SQL with TiKV to provide large‑scale analytical processing.

TiFlash

Columnar storage engine that syncs data from TiKV for fast OLAP queries.

High‑Availability Architecture

TiDB, PD, and TiKV each form Raft groups, allowing the cluster to tolerate node failures without service interruption. TiDB is stateless and can be load‑balanced; PD requires an odd number of nodes for quorum; TiKV maintains multiple replicas per region.

Application Scenarios

MySQL sharding and consolidation – TiDB can act as a MySQL slave to provide real‑time cross‑shard queries.

Direct MySQL replacement – seamless migration without schema changes.

Data warehouse – supports TPC‑H style analytical workloads; TiSpark extends capabilities.

As a module for other systems – TiKV can serve as a high‑performance key‑value store or even replace Redis in certain use cases.

Compatibility and Limitations

TiDB supports most MySQL 5.7 syntax and tools, but lacks stored procedures, triggers, events, custom functions, foreign keys, certain character sets, and some system variables. Features such as SELECT ... INTO @var , GROUP BY ... WITH ROLLUP , and view write operations are not supported.

Default Setting Differences

Character set defaults to utf8mb4 (TiDB) vs latin1 (MySQL 5.7).

Collation defaults to utf8mb4_bin (TiDB) vs utf8mb4_general_ci (MySQL 5.7).

Case‑sensitivity configuration lower_case_table_names is fixed at 2 in TiDB.

Timestamp auto‑update behavior defaults to ON in TiDB.

Foreign key enforcement is disabled by default.

Conclusion

TiDB exemplifies the NewSQL paradigm by delivering a cloud‑native, horizontally scalable, ACID‑compliant relational database that bridges the gap between OLTP and OLAP workloads while maintaining compatibility with the MySQL ecosystem.