Help Center/ TaurusDB/ Service Overview/ Differences Between TaurusDB and RDS for MySQL
Updated on 2025-05-15 GMT+08:00
View PDF
Share

Differences Between TaurusDB and RDS for MySQL

TaurusDB has good performance, scalability, and usability. For details, see Table 1.

Table 1 Differences between TaurusDB Enterprise Edition and RDS for MySQL

Item

RDS for MySQL

TaurusDB Enterprise Edition

Architecture

Traditional primary/standby architecture. Data is synchronized between the primary and standby databases through binlogs.

Decoupled storage and compute architecture. Compute nodes share the same data. Data does not need to be synchronized through binlogs.

Performance

Hundreds of thousands of QPS, three times the performance of the open-source MySQL in high concurrency.

Millions of QPS, seven times the performance of open-source MySQL for certain workloads. In complex queries, operations, such as column extraction, conditional filtering, and aggregation calculation, can be pushed down to the storage layer, improving the performance by dozens of times compared with traditional databases.

Scalability
  • Up to five read replicas can be added for each DB instance. The time required for adding read replicas depends on how much data there is. Adding read replicas require additional storage.
    NOTE:

    RDS for MySQL allows for a maximum of 10 read replicas per DB instance. To use this function, submit a service ticket.

  • The storage grows as needed, to up to 4 TB per DB instance.
  • Up to 15 read replicas can be added for each DB instance. Thanks to the shared storage, the time required for adding read replicas is not affected by how much data there is, and no additional storage is needed for read replica creation.
  • The storage grows as needed, to up to 128 TB per DB instance.

Availability

If the primary instance fails, the standby instance can be automatically promoted to the primary, with an RTO of less than 30s.

If the primary node is faulty, a read replica can be automatically promoted to the primary, with an RTO of less than 10s. It has less latency because no data synchronization through binlogs is required between the primary node and read replicas.

Backup and restoration

Data can be restored to a specific point in time using full backups and binlog playback.

Data can be restored to a specific point in time using full backups (snapshots) and redo log playback, which is faster.

DB engine version

MySQL 5.6, 5.7, and 8.0

MySQL 8.0