MySQL vs ColumnStore vs ClickHouse Benchmark

Choosing the right database for analytics depends on the workload, data size, and query patterns. This blog compares MySQL, MariaDB ColumnStore, and ClickHouse using a large time-series dataset. The benchmark compares storage usage and query performance, with ClickHouse delivering the best results for this particular workload and ultimately being selected for production.

sukan September 10, 2026

Subscribe for email updates

Summarize with AI: ChatGPT Google AI Perplexity Claude Grok

FAQ

ClickHouse is designed for analytical workloads and uses column-oriented storage, allowing it to read and process only the columns required by an analytical query. This is particularly beneficial for large time-series datasets involving filtering, aggregation, and scanning large numbers of rows. In the benchmark, ClickHouse performed particularly well for larger time-series queries compared with MySQL and MariaDB ColumnStore.

MySQL is primarily designed as a row-oriented relational database and is well suited for OLTP workloads. As analytical data volumes grow, queries involving large scans and aggregations can become increasingly expensive. ClickHouse is purpose-built for OLAP and large-scale analytical queries. In the benchmark, MySQL and ColumnStore queries failed when the tested time range reached six months, while ClickHouse continued to perform effectively.

In the benchmark workload, approximately 298.95 GB of MySQL data was reduced to 11.4 GB in ClickHouse, while MariaDB ColumnStore required approximately 24.6 GB. This represents substantially lower storage consumption for the tested time-series dataset. However, these storage ratios should not be treated as universal. Compression and storage efficiency depend on the data types, cardinality, schema, sorting strategy, and workload.

For the specific time-series workload tested in this benchmark, ClickHouse delivered better query performance and lower storage consumption than MariaDB ColumnStore. The benchmark therefore selected ClickHouse for the production workload because it contained primarily append-oriented time-series data with no updates or deletes. This result should not be interpreted as a universal benchmark; database performance depends heavily on workload, schema, hardware, configuration, and query patterns.

ClickHouse is a strong candidate when the workload involves large volumes of analytical or time-series data, particularly when queries perform aggregations and scans across large datasets. MySQL remains a better fit for many transactional workloads involving frequent inserts, updates, deletes, point lookups, and OLTP-style transactions. A common architecture is therefore to keep MySQL as the transactional database and replicate or stream data into ClickHouse for analytics.

Author Bio

sukan

Sukan is Database Team Lead at Mafiree with over a decade of experience in database systems, architecture, and performance optimization. He specializes in MySQL, MongoDB, TiDB, and ClickHouse, developing architectural improvements that make data platforms faster, more efficient, and cost-effective. Sukan writes about practical database engineering topics, real-world performance tuning, data replication, and high-scale system design, drawing from extensive hands-on experience solving complex technical challenges.