Why TiDB Is the Next‑Gen NewSQL Database: Architecture, Features, and Use Cases

TiDB is a distributed NewSQL database that supports horizontal elastic scaling, ACID transactions, standard SQL, MySQL syntax and protocol, and provides strong consistency and high availability, making it suitable for both OLTP and OLAP scenarios.

What is NewSQL

Database development has gone through three generations:

SQL – traditional relational databases such as MySQL.

NoSQL – databases like MongoDB and Redis.

NewSQL.

Problems of Traditional SQL

With the rapid growth of the Internet, user scale and data volume have exploded, demanding 24/7 availability. Traditional relational databases become bottlenecks, and two common solutions are:

Upgrade hardware

Performance improves but eventually hits a ceiling.

Data sharding

Use a distributed cluster architecture.

Sharding splits data across many cheap machines, improving scalability but introducing new complexities such as cross‑shard joins, distributed transactions, and the need for middleware.

NoSQL Problems

NoSQL abandoned strong transactional guarantees and relational models to focus on high availability and scalability.

Advantages

High availability and easy horizontal scaling.

Performance boost by sacrificing strong consistency.

Flexibility without relational constraints.

Disadvantages

Lack of strong consistency, which is required by many enterprise applications.

Incompatible SQL syntax; each NoSQL has its own API.

NewSQL Features

NewSQL offers the same scalability as NoSQL while retaining the relational model and mature SQL language, guaranteeing ACID transactions.

In simple terms, NewSQL integrates NoSQL‑level scalability into traditional relational databases.

NewSQL is born in the cloud era and is inherently distributed.

Main Characteristics of NewSQL

SQL support for complex queries and large‑scale analytics.

Full ACID transaction support with isolation levels.

Elastic scaling that is transparent to the business layer.

High availability with automatic failover.

Three‑SQL Comparison

Traditional SQL, NoSQL, and NewSQL differ in consistency, scalability, and feature sets; NewSQL combines the strengths of the other two.

How TiDB Originated

Huang Dongxu, co‑founder and CTO of PingCAP and former author of the open‑source distributed cache Codis, was inspired by Google’s F1/Spanner papers in 2012, leading to the creation of TiDB.

TiDB Community and Enterprise Editions

TiDB has a free community edition and a paid enterprise edition that provides additional services and security support.

Core Features of TiDB

Horizontal Elastic Scaling

Adding new nodes enables TiDB to scale horizontally for both throughput and storage, handling high concurrency and massive data.

TiDB separates storage and compute, allowing independent scaling of each component without affecting the other.

Distributed Transaction Support

TiDB fully supports standard ACID transactions.

Financial‑Grade High Availability

Based on Raft consensus, TiDB guarantees 100% data consistency and automatic failover without manual intervention.

Data is replicated across multiple nodes; a majority of replicas must acknowledge writes before they are committed.

Real‑time HTAP

TiDB combines an OLTP row‑store (TiKV) with an OLAP column‑store (TiFlash) to provide a unified HTAP solution, eliminating the need for ETL.

TiFlash replicates data from TiKV via Multi‑Raft Learner, ensuring strong consistency between row and column stores.

Cloud‑Native Distributed Database

Designed for cloud environments, TiDB integrates tightly with Kubernetes and supports public, private, and hybrid clouds, simplifying deployment and maintenance.

MySQL Compatibility

TiDB is compatible with MySQL 5.7 protocol and ecosystem; most applications can migrate with little or no code changes.

OLTP & OLAP (Self‑Study)

OLTP (Online Transaction Processing)

OLTP handles high‑frequency, low‑latency transactions such as banking operations, typically processing hundreds to thousands of transactions per second.

OLAP (Online Analytical Processing)

OLAP focuses on complex analytical queries and decision‑support reporting, often processing massive data volumes.

Feature Comparison

OLTP emphasizes real‑time processing of small data sets, while OLAP emphasizes large‑scale data analysis; TiDB supports both workloads simultaneously.

TiDB Overall Architecture

TiDB clusters consist of three core components: TiDB Server (stateless SQL processing), Placement Driver (PD) for metadata and scheduling, and TiKV Server (distributed transactional key‑value storage). TiSpark provides Spark‑SQL integration for heavy OLAP workloads.

TiDB Advantages

Purely distributed architecture with elastic scaling.

SQL support and MySQL protocol compatibility.

Built‑in high availability with automatic data repair.

ACID transaction support for strong consistency needs.

Rich ecosystem of tools for migration, synchronization, and backup.

TiDB Components

TiDB Server

Stateless component that receives SQL requests, parses them, and forwards data operations to TiKV via PD.

PD (Placement Driver) Server

Manages cluster metadata, performs load balancing and region scheduling, and allocates globally unique transaction IDs. PD uses Raft for high availability.

TiKV Server

Distributed transactional key‑value store. Data is divided into Regions, each replicated via Raft. PD schedules Regions across nodes.

TiSpark

Spark plugin that runs Spark SQL directly on TiKV, enabling real‑time big‑data analytics.

TiFlash

Column‑store nodes that accelerate analytical queries by storing data in columnar format.

TiKV Overall Architecture

TiKV stores data in Regions, each with multiple replicas (default three). When a Region exceeds a size limit, it splits; small adjacent Regions merge. PD schedules Region placement, and Raft ensures consistency.

Region Splitting & Merging

Regions larger than 144 MB are split into smaller ones; tiny adjacent Regions are merged to maintain balanced sizes.

Region Scheduling

PD adds a Learner replica to the target node, promotes it to Follower once synchronized, then removes the old replica. Leader transfer follows a similar process.

Distributed Transactions

TiKV supports two‑phase commit, allowing atomic writes across multiple keys regardless of their Region placement.

High‑Availability Architecture

TiDB High Availability

TiDB is stateless; deploying at least two instances behind a load balancer ensures service continuity when one instance fails.

PD High Availability

PD runs as a Raft cluster; losing a non‑leader node has no impact, while leader loss triggers a new election (≈3 seconds).

TiKV High Availability

TiKV uses Raft with configurable replica count (default three). If a node fails, Raft re‑elects a new leader; PD later migrates data from the failed node.

Application Scenarios

MySQL Sharding & Merging

TiDB can act as a MySQL slave, aggregating data from multiple MySQL shards for real‑time cross‑shard queries.

Direct MySQL Replacement

TiDB can replace MySQL without any schema changes, handling scaling and high concurrency automatically.

Data Warehouse

TiDB serves as a distributed data warehouse; with TiSpark, complex analytical queries run directly on TiKV.

Module for Other Systems

TiKV can be used as a key‑value store replacement for systems like HBase, offering transactional APIs.

TiDB vs MySQL Compatibility

Supports MySQL protocol and most syntax; works with MySQL 5.7 tools.

Some MySQL features are unsupported or behave differently (e.g., stored procedures, triggers, certain data types).

Unsupported MySQL Features in TiDB

Stored procedures and functions.

Triggers.

Events.

Custom functions.

Foreign key constraints.

Temporary tables.

Full‑text and spatial indexes.

Various character sets (ascii, latin1, binary, utf8, utf8mb4).

SYSTEM schema.

MySQL optimizer trace.

XML functions.

X‑Protocol.

Savepoints.

Column‑level privileges.

XA syntax (internal two‑phase commit is not exposed).

CREATE TABLE … AS SELECT.

CHECK TABLE.

CHECKSUM TABLE.

GET_LOCK / RELEASE_LOCK functions.

Auto‑Increment ID

TiDB guarantees uniqueness of auto‑increment values within a single TiDB server but does not guarantee continuity across servers. Mixing default and custom values may cause Duplicated Error. The system variable tidb_allow_remove_auto_inc controls whether the AUTO_INCREMENT attribute can be removed.

SELECT Limitations

SELECT ... INTO @var

is not supported. SELECT ... GROUP BY ... WITH ROLLUP is not supported.

Result ordering of SELECT ... GROUP BY expr follows MySQL 8.0 semantics, not guaranteed to be ordered.

Views

TiDB does not support write operations (UPDATE, INSERT, DELETE) on views.

Default Setting Differences

Character Set

TiDB default: utf8mb4.

MySQL 5.7 default: latin1.

MySQL 8.0 default: utf8mb4.

Collation

TiDB default: utf8mb4_bin.

MySQL 5.7 default: utf8mb4_general_ci.

MySQL 8.0 default: utf8mb4_0900_ai_ci.

Case Sensitivity

Configuration lower_case_table_names :

TiDB default: 2 (stores names as given, compares case‑insensitively).

MySQL defaults vary by OS (0 on Linux, 1 on Windows, 2 on macOS).

Timestamp Default Behavior

TiDB default: ON (timestamp updates automatically).

MySQL 5.7 default: OFF.

MySQL 8.0 default: ON.

Foreign Key Support

TiDB default: OFF (cannot be enabled).

MySQL 5.7 default: ON.