Comparison Item | TDSQL-C for MySQL | TencentDB for MySQL |
Database type | A new-generation relational database that is born cloud-native | A high-performance enterprise-grade database service that is specifically tailored based on the open-source MySQL database |
Architecture | Cluster: A cluster can contain only one read-write instance and up to 15 read-only instances. | Single-node: One single node. Two-node: One source node and one replica node. Three-node: One source node and two replica nodes. |
Engine | InnoDB | InnoDB RocksDB |
Version | Compatible with MySQL 5.7 Compatible with MySQL 8.0 | MySQL 5.6 MySQL 5.7 MySQL 8.0 |
Application scenarios | Businesses with great changes, frequent scaling, or needs of read-only instances to improve the read performance. Game projects with frequent quick rollback required Storage and access of petabytes of data Scenarios requiring a high write QPS Scenarios that are sensitive to source-replica delay | Gaming Internet and mobile Apps Finance Ecommerce |
Specification | Up to 88 cores and 710 GB memory per instance | Up to 90 cores and 720 GB memory per instance |
Automatic backup | The default retention time is 7 days, and the maximum retention time can be set to 1830 days. | The default retention time is 7 days, and the maximum retention time can be set to 1830 days. |
Manual backup | Supported | Supported |
Backup file format | Logical Snapshot | Logical Physical |
Serverless | Supports serverless elastic expansion without manual intervention, and scales up or down automatically and quickly. | Unsupported |
Maximum of creatable tables | There are no limits on the number of databases or tables that can be created. In theory, as long as there is enough space, more databases and tables can be created. | The number of tables in a single instance can't exceed 1 million. |
Read/write separation | Supported | Supported |
TencentDB for MySQL (Weaknesses) | TDSQL-C for MySQL (Strengths) |
The upper limit of data storage is limited by a single physical machine. Upgrading specifications and adding read-only instances takes a relatively long time. Strong data consistency requires expensive methods. Binlog-based data sync can't completely solve the source-replica delay. Full logs (redo log, binlog) and data page updates cause write performance bottlenecks. Data rollback and recovery takes too long. | Compute nodes are stateless, and read-only nodes can be upgraded, switched, and added within seconds. Only redo logs are written to implement lightweight writing, delivering a higher write performance (increased by 140%). The source and replica instances are synced based on redo logs. The source instance pushes redo logs, and the replica instances only replay data in the memory without storing it in disks. The replica instance latency is reduced to milliseconds. Strong data consistency is implemented at the block level based on three copies. Distributed storage is supported with up to 400 TB capacity for each instance. Disk capacity expansion is imperceptible to and has no impact on the business. Gigabytes of data can be backed up/rolled back per second to solve the core problems of slow backup and rollback. Serverless capabilities are available. |
Was this page helpful?