What Is TiDB? Exploring the NewSQL Distributed Database and Its Core Features

TiDB is a distributed NewSQL database that supports horizontal elastic scaling, ACID transactions, standard SQL, MySQL syntax and protocol, providing strong data consistency and high availability for both OLTP and OLAP workloads.

What is NewSQL

Database development has gone through three generations: traditional relational databases (SQL) like MySQL, NoSQL databases such as MongoDB and Redis, and NewSQL databases that combine the scalability of NoSQL with the relational model.

Problems with Traditional SQL

With the rapid growth of internet applications, user scale and data volume have increased dramatically, requiring 24/7 availability. Traditional relational databases become bottlenecks; typical solutions are upgrading hardware or sharding data across distributed clusters, each bringing new complexities.

Upgrade hardware

Improves performance but eventually hits a ceiling.

Data sharding

Distributes data across cheap machines in a cluster, improving scalability but introducing middleware, cross‑shard joins, and distributed transactions that increase application complexity.

NoSQL Issues

NoSQL sacrifices strong transaction guarantees and relational models for high availability and scalability.

Advantages

High availability and automatic partitioning.

Performance gains by relaxing strong consistency.

Flexibility without relational constraints.

Disadvantages

Lack of strong consistency, which many enterprise applications require.

Incompatible SQL support; each NoSQL has its own API.

NewSQL Characteristics

NewSQL offers NoSQL‑level scalability while retaining the relational model and mature SQL query language, guaranteeing ACID transactions.

Main Features of NewSQL

SQL support for complex queries and big‑data analytics.

ACID transactions with isolation levels.

Elastic scaling transparent to the business layer.

High availability with automatic failover.

Three‑SQL Comparison

How TiDB Originated

TiDB was created by PingCAP co‑founder Huang Dongxu after reading Google’s F1/Spanner papers in 2012, aiming to build a globally distributed, strongly consistent relational database.

TiDB Community and Enterprise Editions

TiDB offers a free community edition and a paid enterprise edition that adds services and security support.

Core TiDB Features

Horizontal Elastic Scaling

Adding new nodes expands capacity and throughput without downtime.

Distributed Transaction Support

TiDB fully supports standard ACID transactions.

Financial‑Grade High Availability

Based on Raft consensus, TiDB provides 100 % data consistency and automatic failover.

Real‑time HTAP

TiDB combines row‑store TiKV and column‑store TiFlash to handle OLTP and OLAP on the same data without ETL.

Cloud‑Native Architecture

Designed for cloud environments, TiDB integrates tightly with Kubernetes and runs on public, private, or hybrid clouds.

MySQL Compatibility

TiDB speaks the MySQL 5.7 protocol and supports most MySQL syntax and ecosystem tools, enabling seamless migration.

OLTP & OLAP Overview

OLTP

Online Transaction Processing handles high‑frequency, low‑latency transactions such as banking operations.

OLAP

Online Analytical Processing focuses on complex analytical queries over large data volumes, emphasizing throughput rather than latency.

TiDB Architecture

TiDB Server

Stateless SQL layer that parses queries and forwards them to storage via PD.

Placement Driver (PD)

Manages metadata, schedules region placement, and allocates global transaction IDs using Raft.

TiKV Server

Distributed transactional key‑value store; data is split into Regions replicated via Raft.

TiSpark

Spark plugin that runs SQL directly on TiKV, enabling large‑scale OLAP.

TiFlash

Columnar storage node that accelerates analytical workloads.

High‑Availability Design

TiDB, PD, and TiKV can tolerate node failures; each component uses Raft to ensure data safety and automatic leader election.

Use Cases

MySQL sharding and consolidation using TiDB as a unified backend.

Direct replacement of MySQL for growing OLTP workloads.

Data warehouse for complex analytical queries, optionally with TiSpark.

Component for other systems, e.g., using TiKV as a key‑value store or Redis replacement.

Unsupported MySQL Features

Stored procedures, triggers, events, custom functions.

Foreign keys, temporary tables.

Full‑text/spatial indexes.

Various character sets beyond utf8mb4.

VIEW write operations, certain SELECT syntaxes, and some system variables.

Configuration Differences

Character Set

TiDB defaults to utf8mb4.

MySQL 5.7 defaults to latin1; MySQL 8.0 defaults to utf8mb4.

Collation

TiDB uses utf8mb4_bin.

MySQL 5.7 uses utf8mb4_general_ci; MySQL 8.0 uses utf8mb4_0900_ai_ci.

Case Sensitivity

TiDB enforces lower_case_table_names=2 (stores names as given but compares case‑insensitively).

Timestamp Behavior

TiDB default ON (auto‑update on row change).

MySQL 5.7 default OFF; MySQL 8.0 default ON.

Foreign Key Support

TiDB default OFF.

MySQL 5.7 default ON.