Evolution and Technical Analysis of Tencent Cloud Databases: TDSQL and CynosDB

Since the 1950s and 1960s, the term "data" has evolved from simple numeric information to a complex concept encompassing a wide range of digital assets. As information technology advanced, the scope of data storage and processing expanded, and the discipline of databases grew rapidly.

Tencent Cloud’s journey in the database field mirrors that of many internet companies: moving from using open‑source solutions to custom adaptations and finally to independent R&D. Unlike early IOE‑centric enterprises that heavily relied on commercial databases such as Oracle, Tencent initially had little dependence on databases. Its early cloud database work began with key‑value and analytical storage, later transitioning to relational databases.

Two development tracks of Tencent Cloud databases

1. Embracing open source – Open‑source customization → Contributing back → Cloud‑native customization → Customer‑driven adaptation.

Initially, Tencent Cloud integrated mainstream open‑source databases such as MySQL, Redis, and PostgreSQL. It then added core features like parallel replication, audit logs, and online schema changes, and contributed many of these improvements back to the MariaDB and MySQL communities.

2. Internal independent R&D – Business‑driven technology evolution → Cloud‑native support → Expansion to internet and traditional industries.

To move beyond the cost‑saving focus of the 1.0 era, Tencent Cloud pursued self‑developed databases that could provide capabilities unattainable by off‑the‑shelf solutions. Two main families emerged:

Databases built specifically for internal Tencent services, exemplified by TDSQL .

Cloud‑native, enterprise‑grade databases derived from open‑source bases, such as CynosDB .

Technical deep‑dive of TDSQL

Founded in 2007 to guarantee high availability and zero data loss for billing and core transactions, TDSQL evolved into a full‑featured distributed database by 2012. Its architecture follows a Shared‑Nothing design and supports multi‑tenant deployments.

The system consists of a decision‑scheduling cluster (GTM), an SQL engine, and a data storage layer. Core components include:

Scheduler – manages coordination (Zookeeper + scheduler server).

Gateway – the access layer composed of multiple gateways.

Agent – execution agents that work with MySQL instances to form data nodes; groups of nodes constitute a SET.

Key architectural concepts are replica (for availability) and sharding (for capacity scaling). TDSQL introduces a thread‑pool model and a group‑commit mechanism to avoid blocking on network I/O. The binlog replication workflow is split into three stages: (1) write to binlog and store the session, (2) dump thread sends the binlog to the replica, (3) the master processes acknowledgments via a dedicated response thread, enabling fast fail‑over and strong consistency.

TDSQL also implements a cost‑based optimizer (CBO) that pushes down predicates, shard‑key filters, index conditions, null checks, sub‑queries, and left‑join transformations (up to 18 optimization techniques) to reduce cross‑node data transfer.

Technical deep‑dive of CynosDB

Launched in 2017 after serving millions of customers, CynosDB is a truly cloud‑native database that achieves up to 1.3 million QPS per node, surpassing industry benchmarks.

Design principles

Compute‑storage separation – independent scaling of CPU/memory and storage.

Log sinking and asynchronous replay – removes page‑level write‑back logic, reducing network overhead.

Distributed storage – a shared, horizontally scalable storage system.

Continuous log backup – performed at the storage layer without impacting the database instance.

CynosDB’s architecture eliminates traditional I/O bottlenecks by treating logs as the sole data carrier. Logs are sharded across storage cells, asynchronously persisted, and later replayed to materialize pages. A thread‑pool handles short‑lived tasks, while a dedicated log‑writer thread performs asynchronous group commits, dramatically reducing context‑switch overhead.

Log sinking means that all DB‑generated logs are placed into a dedicated buffer (CynosStore Client) and asynchronously flushed to distributed storage, decoupling write latency from the compute layer. This design enables sub‑second fail‑over, 180× faster backup, and seamless scaling.

CynosDB is positioned for a wide range of scenarios, from internet services to gaming, and is slated for full commercial launch in Q3, with usage‑based billing already supported.

Conclusion

From 2012 to 2019, Tencent Cloud’s database portfolio progressed from open‑source adoption to deep customization and finally to independent R&D, producing landmark products such as TDSQL and CynosDB. The ongoing shift toward cloud‑native technologies presents both challenges and opportunities for database administrators, product engineers, and the broader ecosystem.