What Is NewSQL? Exploring TiDB’s Distributed Database Features

What is NewSQL

Database development has gone through three generations:

SQL, traditional relational databases such as MySQL

NoSQL, such as MongoDB, Redis

NewSQL

Problems of Traditional SQL

Since the early 2000s, the rapid growth of the Internet has increased user scale and data volume, requiring 24/7 availability. Traditional relational databases become bottlenecks under such conditions, typically addressed by two methods:

Upgrade server hardware

Improves performance but eventually hits a ceiling.

Data sharding

Using a distributed cluster structure

Sharding a single‑node database across cheap machines improves scalability, but introduces new challenges. Data now spans multiple databases, requiring sharding middleware for cross‑database operations, and complex queries like cross‑database joins or transactions become difficult.

Problems of NoSQL

NoSQL emerged, sacrificing strong transactional guarantees and relational models for high availability and scalability.

Advantages

High availability and scalability, automatic partitioning

Does not guarantee strong consistency; performance improves significantly

No relational model constraints, extremely flexible

Disadvantages

Lacks strong consistency; unsuitable for enterprise applications requiring strict consistency

Does not support SQL; each NoSQL has its own API, increasing complexity

NewSQL Features

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

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

Traditional SQL architectures are not distributed, whereas NewSQL, born in the cloud era, is inherently distributed.

Main Characteristics of NewSQL

SQL support, enabling complex queries and big‑data analysis

Supports ACID transactions and isolation levels

Elastic scaling; capacity changes are transparent to the application layer

High availability with automatic disaster recovery

Comparison of the Three SQL Types

What Is TiDB

TiDB is a distributed NewSQL database. It 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.

TiDB is an open‑source distributed relational database designed by PingCAP. It supports hybrid transactional and analytical processing (HTAP), offers horizontal scaling, financial‑grade high availability, real‑time HTAP, cloud‑native deployment, and full compatibility with MySQL 5.7.

Its goal is to provide a one‑stop solution for OLTP, OLAP, and HTAP. TiDB fits use cases requiring high availability, strong consistency, and large data volumes.

TiDB is available in a community edition and an enterprise edition (the latter includes paid support and security features).

Core Features of TiDB

Horizontal Elastic Scaling

Adding new nodes enables horizontal scaling of throughput and storage, handling high concurrency and massive data.

Thanks to TiDB’s separation of storage and compute, scaling can be performed independently and transparently to applications.

Distributed Transaction Support

TiDB fully supports standard ACID transactions.

Financial‑Grade High Availability

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

Data is stored with multiple replicas synchronized via Multi‑Raft; transactions are committed only after a majority of replicas acknowledge, ensuring strong consistency even when some replicas fail.

Real‑time HTAP

TiDB combines OLTP row‑store (TiKV) and OLAP column‑store (TiFlash). TiFlash replicates data from TiKV in real time using Multi‑Raft Learner, guaranteeing strong consistency between the two engines.

Cloud‑Native Distributed Database

TiDB is designed for the cloud and tightly integrated with Kubernetes, supporting public, private, and hybrid clouds. Its design targets 100% OLTP and 80% OLAP workloads; more complex OLAP queries can be offloaded to TiSpark.

High Compatibility with MySQL

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

Rich migration tools simplify data migration, allowing seamless transition from MySQL to TiDB.

OLTP & OLAP

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, emphasizing throughput of large data scans rather than transaction latency.

TiDB Overall Architecture

Advantages

Purely distributed architecture with excellent scalability and elastic scaling

SQL support with MySQL protocol compatibility, allowing direct replacement of MySQL in most scenarios

Built‑in high availability; the cluster can automatically recover from partial failures

Supports ACID transactions, suitable for strong‑consistency use cases such as banking transfers

Rich ecosystem of tools for data migration, synchronization, backup, and more

Components

TiDB clusters consist of three core components: TiDB Server, Placement Driver (PD) Server, and TiKV Server, plus TiSpark for complex OLAP needs.

TiDB Server

Stateless component that receives SQL requests, parses them, and interacts with PD to locate TiKV nodes for data access. It can be horizontally scaled behind a load balancer.

PD (Placement Driver) Server

Manages cluster metadata, schedules and balances load across TiKV, and allocates globally unique, monotonically increasing transaction IDs. PD uses Raft for safety and should be deployed with an odd number of nodes.

TiKV Server

Distributed transactional key‑value storage engine. Data is divided into Regions, each replicated via Raft. PD schedules Regions across TiKV nodes for balanced load.

TiSpark

Runs Spark SQL directly on TiKV storage, enabling real‑time HTAP without data duplication.

TiFlash

Column‑store nodes that accelerate analytical workloads, replicating data from TiKV in real time.

TiKV Overall Architecture

TiKV splits data into Regions (key ranges) with multiple replicas (typically three). PD schedules Regions and replicas, and Raft ensures consistency. Regions larger than 144 MB are split; small adjacent Regions are merged.

Region scheduling involves adding a learner replica on the target node, promoting it to follower once synchronized, and then removing the old replica.

High‑Availability Architecture

TiDB High Availability

TiDB is stateless; deploying at least two instances behind a load balancer ensures that a single instance failure only affects the current session.

PD High Availability

PD forms a Raft cluster; if the leader fails, a new leader is elected within a few seconds. Deploy at least three PD instances.

TiKV High Availability

TiKV stores data with multiple replicas; Raft ensures consistency. If a node fails, its Regions are re‑replicated to other nodes after a timeout.

Application Scenarios

MySQL Sharding and Merging

TiDB can act as a MySQL slave using PingCAP’s Syncer tool, enabling real‑time cross‑shard queries without complex middleware.

Direct MySQL Replacement

For workloads that have outgrown single‑node MySQL, TiDB provides a drop‑in replacement with automatic horizontal scaling and strong consistency.

Data Warehouse

TiDB can serve as a data warehouse; with TiSpark, it can execute complex analytical queries in seconds.

Module for Other Systems

TiKV can be used as a replacement for HBase, offering transactional capabilities via raw API or ACID transaction API.

TiDB vs MySQL Compatibility

TiDB supports MySQL protocol and most syntax, allowing migration without code changes.

Supported MySQL version is 5.7; most MySQL tools work with TiDB.

Some features are unsupported or behave differently, such as stored procedures, triggers, events, custom functions, foreign keys, temporary tables, full‑text/spatial indexes, certain character sets, and XA transactions.

Unsupported MySQL Features

Stored procedures and functions

Triggers

Events

Custom functions

Foreign key constraints

Temporary tables

Full‑text/spatial functions and indexes

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

SYS schema

MySQL optimizer trace

XML functions

X‑Protocol

Savepoints

Column‑level privileges

XA syntax (TiDB uses two‑phase commit internally)

CREATE TABLE … AS SELECT

CHECK TABLE

CHECKSUM TABLE

GET_LOCK and RELEASE_LOCK functions

SELECT Limitations

Does not support SELECT … INTO @var syntax.

Does not support SELECT … GROUP BY … WITH ROLLUP.

GROUP BY results are unordered, matching MySQL 8.0 behavior.

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 utf8mb4 default collation: utf8mb4_bin MySQL 5.7 default collation: utf8mb4_general_ci MySQL 8.0 default collation:

utf8mb4_0900_ai_ci

Case Sensitivity

Configuration of lower_case_table_names differs across systems; TiDB only supports the value 2.

Timestamp Column Behavior

TiDB default: ON (auto‑update on row change, cannot be turned off)

MySQL 5.7 default: OFF MySQL 8.0 default:

ON

Foreign Key Support

TiDB default: OFF (cannot be enabled)

MySQL 5.7 default:

ON