Inside TDSQL-C: Tencent’s Cloud‑Native Database Scaling Globally with High Performance

TDSQL‑C Overview

TDSQL‑C is Tencent Cloud's self‑developed next‑generation cloud‑native relational database. It merges the strengths of traditional databases, cloud computing, and modern hardware to provide highly elastic, high‑performance, massive‑scale, and secure database services. The MySQL edition is 100% compatible with MySQL 5.7 and 8.0, supporting over one million QPS and petabyte‑level intelligent storage.

TDSQL‑C Technical Architecture Evolution

TDSQL‑C Technical Evolution Roadmap

2017‑2019: Project launched, based on storage‑compute separation to solve independence and elastic scaling; commercialized in 2019 as one of the first cloud‑native database products.

2021: Serverless version released, the first serverless cloud‑native database in China, serving over 100,000 enterprises and 500,000 WeChat mini‑program developers.

2023: Parallel query and column‑store index added, HTAP capability enhanced, complex query speed improved 4‑17×.

2025 (planned): Global database version to synchronize data across multiple regional clusters, facilitating seamless global deployment.

TDSQL‑C Global Database Core Technology

Global Database Architecture

The global database spans cities, countries, and even continents, forming a networked cluster with full data sets replicated across regions. One primary region can have up to seven secondary regions, each mounting up to 15 read‑only replicas, achieving near‑local reads and multi‑region disaster recovery.

Write requests in the primary region generate redo logs stored in a high‑speed LOGSTORE and backed up to COS. Standby nodes in secondary regions sync these logs, allowing read‑only nodes to update memory and serve consistent data. Write requests from a secondary region are transparently forwarded to the primary region via Proxy or direct kernel connections.

Underlying Storage Engine DBSTORE 3.0

To support global database capabilities, the storage engine upgraded from DBSTORE 2.0 to 3.0.

DBSTORE 2.0 Architecture

DBSTORE 2.0 follows the “Log Is Database” principle, where logs contain complete data information, enabling recovery without page‑level replay. Benefits include stateless compute nodes, zero page‑restore overhead, and reduced write amplification.

However, DBSTORE 2.0 faced challenges such as fragmented redo logs, complex redesign requirements for continuous backup, and performance penalties.

DBSTORE 3.0 Architecture

DBSTORE 3.0 introduces a LOGSTORE component for receiving and persisting redo logs and upgrades PAGESTORE for asynchronous batch distribution and partial compute functions. This logical decoupling lets each component play to its strengths, eliminating master‑node bottlenecks and reducing network latency.

Log Function Enhancements

To meet global data set demands, standby nodes must provide continuous log streams and subscription capabilities. Two modules are used: a log ring buffer for recent logs in memory and a CDP Agent for subscribing to a range of logs from storage. Standby nodes read logs from the ring buffer when possible; otherwise they fetch from LOGSTORE or COS, making log retrieval transparent to the database instance.

Send‑Efficiency Optimization

Cross‑continent deployments suffer from high latency; for example, Guangzhou‑to‑Santa Clara limited single‑thread log transmission to 15 MB/s. The solution adds a coordinating thread and multiple worker threads that slice log ranges and send them in parallel, achieving throughput proportional to thread count (e.g., 16 threads meet most production scenarios, 24 threads handle high‑throughput global replication).

Availability‑Zone Switching

Two switching modes exist:

Planned switching : Used for version upgrades or load‑driven migrations. The primary is demoted to standby, logs are synchronized, and a qualified standby is promoted to primary via change‑master commands.

Unplanned switching : Triggered by zone failures. The most up‑to‑date standby is selected, ensures all logs are applied, rolls back incomplete transactions, and is then promoted to primary. Other regions redirect to the new primary, and the failed zone is rebuilt after recovery.

Write Forwarding

The global database supports transparent write forwarding from secondary regions, either via Proxy or kernel‑level forwarding. Clients can choose among eventual, session, or global consistency levels, balancing latency against data consistency.

Future Outlook – Building Cloud‑Native Databases on Cloud Infrastructure

TDSQL‑C aims for deeper cloud‑native integration, fully embracing cloud infrastructure for both compute and storage, eliminating physical‑node constraints, and delivering full‑stack serverless elasticity, CPU/memory and storage decoupling, and more stable, high‑quality cloud data services.

以上内容来自冉仟元老师的分享。