Why TiDB Is the Leading NewSQL Database for HTAP Workloads

What Is NewSQL?

NewSQL emerged to provide the scalability of NoSQL while retaining the relational model and SQL query language, ensuring ACID transactions. It bridges the gap between traditional relational databases and modern distributed systems.

Problems with Traditional SQL and NoSQL

Traditional relational databases struggle with massive data volumes and 24/7 availability, leading to hardware upgrades or data sharding, which introduces complexity in cross‑shard joins and transactions. NoSQL offers high availability and scalability but sacrifices strong consistency and SQL compatibility, making it unsuitable for many enterprise applications.

TiDB Overview

TiDB, developed by PingCAP, is a distributed NewSQL database that supports horizontal elastic scaling, ACID transactions, the MySQL 5.7 protocol, and both OLTP and OLAP workloads (HTAP). It is designed for cloud‑native environments and can run on public, private, or hybrid clouds.

Origin of TiDB

Inspired by Google’s F1/Spanner papers in 2012, PingCAP founder Huang Dongxu built TiDB to bring Google‑scale distributed relational capabilities to the open‑source community.

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

Horizontal elastic scaling – add or remove nodes to adjust capacity without downtime.

Distributed ACID transactions with full isolation levels.

Financial‑grade high availability using Raft‑based majority election.

Real‑time HTAP – TiDB Server handles OLTP while TiFlash provides column‑store acceleration for OLAP queries.

Cloud‑native architecture tightly integrated with Kubernetes.

High compatibility with MySQL 5.7 syntax, protocols, and ecosystem tools.

OLTP vs. OLAP

OLTP focuses on high‑throughput, low‑latency transactional processing (e.g., banking, e‑commerce), while OLAP handles large‑scale analytical queries for decision support. TiDB unifies both on a single storage layer, eliminating the need for separate ETL pipelines.

Architecture Components

TiDB Server

Stateless SQL processing layer that receives queries, looks up data locations via PD, and interacts with TiKV for storage.

Placement Driver (PD)

Stores cluster metadata (key‑to‑region mapping).

Schedules and load‑balances TiKV regions.

Generates globally unique, monotonically increasing transaction IDs.

TiKV Server

Distributed key‑value store that manages data in Region units, replicates using Raft, and ensures strong consistency.

TiFlash

Column‑store node that syncs data from TiKV via Multi‑Raft Learner and accelerates analytical queries.

TiSpark

Spark plugin that runs Spark SQL directly on TiKV, enabling large‑scale data analysis without data movement.

High‑Availability Design

All three components (TiDB, PD, TiKV) are designed to tolerate node failures. PD uses Raft to elect a new leader within seconds; TiKV automatically re‑replicates lost replicas; TiDB instances are stateless and can be load‑balanced.

Application Scenarios

MySQL sharding and consolidation – TiDB can act as a MySQL slave to synchronize data and simplify cross‑shard queries.

Direct MySQL replacement – seamless migration with minimal code changes, benefiting from horizontal scalability.

Data warehouse – TiDB 2.0 delivers sub‑10‑second query times on TPC‑H benchmarks; TiSpark extends Spark analytics to TiKV data.

Backend for other systems – TiKV can serve as a distributed KV store (e.g., HBase replacement) with optional raw API for high‑performance, non‑transactional workloads.

Compatibility and Limitations

TiDB supports most MySQL 5.7 syntax and tools, but lacks stored procedures, triggers, events, foreign keys, and certain SELECT extensions. Some MySQL features are parsed but ignored (e.g., ENGINE clause).

Configuration Differences

Auto‑Increment

Auto‑increment columns guarantee uniqueness only within a single TiDB server; they are not globally sequential. The system variable tidb_allow_remove_auto_inc controls whether the AUTO_INCREMENT attribute can be removed.

SELECT Restrictions

Unsupported: SELECT ... INTO @var, SELECT ... GROUP BY ... WITH ROLLUP.

GROUP BY ordering follows MySQL 8.0 semantics, not MySQL 5.7.

Views

TiDB does not support UPDATE/INSERT/DELETE on views.

Default Settings

Character set: TiDB defaults to utf8mb4 (same as MySQL 8.0), while MySQL 5.7 defaults to latin1.

Collation: TiDB uses utf8mb4_bin by default. lower_case_table_names is fixed at 2 in TiDB.

Timestamp behavior: explicit_defaults_for_timestamp defaults to ON in TiDB.

Foreign key support is disabled (value OFF only).

Visual Overview