Why TiDB Leads the NewSQL Landscape for HTAP and Cloud‑Native Workloads

What Is NewSQL

Database technology has progressed through three generations: traditional relational SQL databases (e.g., MySQL), NoSQL systems (e.g., MongoDB, Redis), and the emerging NewSQL class.

Problems With Traditional SQL

Rapid growth of internet services demands 24/7 availability and massive scale, exposing bottlenecks in single‑node relational databases. Two common remedies are upgrading hardware and sharding data across a distributed cluster, but both introduce new complexities such as cross‑shard joins and distributed transactions.

Issues With NoSQL

NoSQL sacrifices strong ACID guarantees and the relational model to achieve high availability and horizontal scalability, which leads to weak consistency and limited SQL compatibility.

NewSQL Characteristics

NewSQL combines the scalability of NoSQL with the mature relational model and SQL query language, preserving ACID transactions while being built for cloud‑native, distributed environments.

Main NewSQL Features

Full SQL support for complex queries and analytics.

ACID transactions with isolation levels.

Elastic scaling that is transparent to applications.

High availability with automatic failover.

Three‑SQL Comparison

How TiDB Originated

PingCAP co‑founder Huang Dongxu, inspired by Google’s F1/Spanner papers, created TiDB as a distributed NewSQL database that offers horizontal elasticity, ACID compliance, MySQL compatibility, and HTAP capabilities.

Community vs. Enterprise Editions

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

TiDB Core Features

Horizontal elastic scaling.

Distributed transaction support (100% ACID).

Financial‑grade high availability via Raft consensus.

Real‑time HTAP with TiKV (row store) and TiFlash (column store).

Cloud‑native design tightly integrated with Kubernetes.

High compatibility with MySQL 5.7 protocol and ecosystem.

OLTP & OLAP Overview

OLTP handles high‑frequency, short‑duration transactions (e.g., banking), while OLAP focuses on large‑scale analytical queries. TiDB unifies both workloads, eliminating the need for separate systems.

TiDB Architecture

The cluster consists of three core components:

TiDB Server – stateless SQL processing layer.

PD (Placement Driver) – metadata management, scheduling, and global transaction ID allocation.

TiKV Server – distributed key‑value storage engine using Raft for replication.

Additional modules: TiSpark for Spark‑SQL integration and TiFlash for column‑store acceleration.

TiKV Architecture

Data is split into Regions (key ranges) that are replicated across multiple nodes.

Regions can split when they grow beyond a size limit or merge when they shrink.

PD schedules Region placement and load balancing.

Distributed transactions are implemented via two‑phase commit.

High‑Availability Design

TiDB Server: deploy multiple stateless instances behind a load balancer.

PD: run an odd number of nodes (minimum three) to maintain Raft quorum.

TiKV: default three‑replica Raft groups; failed nodes trigger leader election and data migration.

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, benefiting from horizontal scalability.

Data warehouse – TiDB 2.0 delivers sub‑10‑second query latency for TPC‑H workloads; TiSpark enables large‑scale Spark analytics on TiKV data.

Backend for other systems – TiKV can serve as a key‑value store replacement for HBase or Redis‑compatible services.

MySQL Compatibility

TiDB supports the MySQL 5.7 protocol, most syntax, and tools such as MySQL Workbench, mysqldump, and PHPMyAdmin. However, several MySQL features are not supported or behave differently, including stored procedures, triggers, events, custom functions, foreign keys, temporary tables, full‑text/spatial indexes, and certain character‑set options.

Unsupported MySQL Features

Stored procedures and functions.

Triggers, events, and custom functions.

Foreign‑key constraints.

Temporary tables.

Full‑text and spatial indexes.

Some character sets (ascii, latin1, binary, utf8, utf8mb4) and collations.

XA transactions, SELECT … INTO variables, GROUP BY … WITH ROLLUP, and certain ALTER TABLE operations.

Auto‑Increment Behavior

TiDB guarantees uniqueness but not monotonic continuity across multiple TiDB servers. The system variable tidb_allow_remove_auto_inc controls whether AUTO_INCREMENT can be removed.

SELECT Limitations

No support for SELECT ... INTO @var syntax.

No support for GROUP BY ... WITH ROLLUP.

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

View Restrictions

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

Default Setting 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 (lower_case_table_names): TiDB only supports value 2; MySQL varies by OS.

Timestamp handling: TiDB defaults to ON (auto‑update), MySQL 5.7 defaults to OFF, MySQL 8.0 defaults to ON.

Foreign‑key support: TiDB defaults to OFF and cannot be enabled; MySQL 5.7 defaults to ON.