ApsaraDB RDS for MySQL analytical read-only instances use a built-in DuckDB engine with columnar storage and vectorized execution to handle complex analytical queries at speeds up to 100 times faster than InnoDB. Run your existing MySQL queries directly on real-time data — no schema changes, no external OLAP (online analytical processing) pipeline required.
Key features
High-performance analytics
The DuckDB engine combines columnar storage, vectorized execution, just-in-time (JIT) compilation, efficient memory management, and parallel processing to accelerate complex analytical queries. In TPC-H sf-100 benchmarks, a DuckDB-based analytical read-only instance completed all 22 queries in 15.31 seconds total — compared to 25,234.31 seconds for InnoDB and 80.01 seconds for ClickHouse Community Edition.
MySQL compatibility
The analytical read-only instance is 100% compatible with the MySQL protocol and data types, and supports over 99.9% of SQL syntax, including Data Definition Language (DDL). Submit your existing queries without modification — the instance handles the rest.
Real-time data synchronization
Data flows from the primary instance to the analytical read-only instance through two phases:
Historical data: When the analytical read-only instance is created, the system copies all existing data from the primary instance and converts it to the DuckDB engine format automatically.
Incremental data: After creation, a native binary logging replication channel syncs new writes in real time. The data stays within RDS — no external synchronization tools such as DTS are needed, and there are no extra fees for data synchronization.
Resource isolation
Analytical queries run on the dedicated analytical read-only instance, keeping the primary instance and standard read-only instances free for transaction processing. Heavy queries on one side have no impact on the other.
Use cases
Aggregation and analysis: Run aggregate queries on large datasets such as log data with significantly lower latency than row-based storage.
Multi-table JOIN queries: Execute complex multi-table
JOINqueries that are impractical on a standard MySQL instance.
How it compares
Use a DuckDB-based analytical read-only instance when you need strong analytical query performance with no changes to your existing MySQL setup. The following table summarizes key differences across instance types.
| DuckDB-based analytical read-only instance | Standard read-only instance | OLAP database | |
|---|---|---|---|
| Best for | Complex analytical queries | Transaction processing | Complex analytical queries |
| Query performance | Strong | Low | Strong |
| Data sync method | Native binary logging replication | Native binary logging replication | DTS data synchronization link |
| MySQL protocol | Fully compatible | Fully compatible | Incompatible |
| SQL syntax | Highly compatible (over 99.9%) | Fully compatible | Incompatible (requires SQL rewrite) |
| DDL | Highly compatible | Fully compatible | Partially compatible |
| Data types | Fully compatible | Fully compatible | Incompatible (requires field mapping) |
| O&M costs | Low (integrated instance) | Low (integrated instance) | High (requires extra maintenance for the database and synchronization link) |
Appendix: performance benchmark
The following results use the standard TPC-H benchmark to demonstrate the analytical query performance of a DuckDB-based analytical read-only instance.
Test environment
| Item | Details |
|---|---|
| Dataset | TPC-H sf-100, 100 GB, sourced from the official DuckDB website |
| Host specs | 32-core CPU, 128 GB memory, enterprise SSD storage (same ECS host for all instances) |
| Comparison instances | ApsaraDB RDS for MySQL 8.0.36 (InnoDB engine), ClickHouse Community Edition 25.3 |
| Test method | 3 warm-up rounds (not counted) + 3 official rounds; final result is the average of official rounds |
Test results
The following table shows the running time (in seconds) for each TPC-H sf-100 query.
| Query ID | DuckDB-based analytical read-only instance | Standard ApsaraDB RDS for MySQL instance (InnoDB engine) | ClickHouse |
|---|---|---|---|
| q1 | 0.92 | 1134.25 | 3.47 |
| q2 | 0.15 | 1800 | 1.52 |
| q3 | 0.53 | 802.94 | 3.65 |
| q4 | 0.46 | 1000.45 | 2.77 |
| q5 | 0.5 | 1800 | 5.38 |
| q6 | 0.22 | 566.73 | 0.73 |
| q7 | 0.59 | 1800 | 6.06 |
| q8 | 0.68 | 1800 | 6.99 |
| q9 | 1.44 | 1800 | 13.29 |
| q10 | 0.91 | 894.35 | 3.22 |
| q11 | 0.11 | 79.63 | 1.1 |
| q12 | 0.44 | 734.35 | 1.69 |
| q13 | 1.59 | 454.15 | 5.85 |
| q14 | 0.38 | 574.07 | 0.83 |
| q15 | 0.31 | 568.43 | 1.53 |
| q16 | 0.32 | 63.56 | 0.52 |
| q17 | 0.89 | 1800 | 7.96 |
| q18 | 1.59 | 1800 | 3.11 |
| q19 | 0.8 | 1800 | 2.96 |
| q20 | 0.51 | 1800 | 3.38 |
| q21 | 1.64 | 1800 | Out of memory |
| q22 | 0.33 | 361.4 | 4 |
| Total | 15.31 | 25234.31 | 80.01 |
Test conclusions
DuckDB-based analytical read-only instance vs. ApsaraDB RDS for MySQL instance (InnoDB engine)
The DuckDB-based analytical read-only instance completed all 22 queries in 15.31 seconds. The InnoDB instance took 25,234.31 seconds — a performance gap of more than 1,000x. Nine queries (q5, q7, q8, q9, q17, q18, q19, q20, q21) timed out on InnoDB at the 1,800-second limit and could not complete.
DuckDB-based analytical read-only instance vs. ClickHouse
ClickHouse completed the benchmark in 80.01 seconds. The DuckDB-based analytical read-only instance finished in 15.31 seconds and outperformed ClickHouse on every query that both instances completed. ClickHouse failed q21 with a Memory limit exceeded error.