Cloud Parts

ClickBench

How fast analytical databases run 43 SQL queries over one 100-million-row table of web analytics events, on the same cloud machines.

Real-time analytics databasesData warehousesQuery enginesRun by ClickHouse Inc.License CC BY-NC-SA 4.0Results Source code

What it runs

Every entry loads the same table, hits: 99,997,497 rows and 105 columns of anonymised pageview events taken from the traffic of a large web analytics platform. The data is published as CSV, TSV, JSON lines and Parquet (one 14.8 GB file, or the same data split into 100 files for engines that read files in place). Then 43 SQL queries run one after another: counts, GROUP BY with top-N, distinct counts, LIKE and regex matching on URLs and search phrases, and filters on dates and counters. The queries stay close to standard SQL so most systems can run them unchanged.

Each system has a directory in the repository with scripts to install it, start it, load the data and run the queries on a fresh VM. Every query runs three times. The first run is the cold run: the database is restarted and the OS page cache dropped before it. The faster of the second and third runs is the hot run. The scripts also record load time and data size on disk, and the result goes into a JSON file named after the machine and the date of the run.

The dashboard turns these timings into a relative score. For each query it finds the fastest entry and divides every other entry’s time by it, after adding 10 ms to both so near-zero times don’t dominate. A query that failed counts as twice the entry’s slowest time, or at least 600 seconds. The geometric mean of the 43 ratios is the score: 1.0 would mean fastest on every query. The default “Combined” view weights load time 10%, data size 10%, cold runs 20% and hot runs 60%.

Setup

Dataset
One flat table, hits: 99,997,497 rows, 105 columns, 14.8 GB as Parquet
Queries
43 SQL queries, run one at a time, three runs each
Metrics
Cold run, hot run, load time, data size, and a weighted “Combined” score (the default)
Score
Geometric mean of each query’s time relative to the fastest entry on that query
Default hardware
AWS c6a.4xlarge (16 vCPU, 32 GiB) with a 500 GB gp2 disk
Other machines
c6a.large to c6a.metal, c7a.metal-48xl, Graviton c8g.4xlarge and c8g.metal-48xl, t3a.small; managed services on their own sizes
Who submits results
Anyone, by pull request; the ClickHouse team reruns the automated entries across machines
Entries
182 directories with published results (October 2026); many are variants of one system, such as Parquet, partitioned or tuned setups

What the numbers don’t tell you

  • ClickHouse Inc. runs it, and ClickHouse is one of the entrants. The benchmark began in 2013 as the test that led its authors to choose ClickHouse for production, and the data shape (one wide, denormalised table of events) is the workload ClickHouse was built for. The team says it never tuned ClickHouse for these queries, but it chose the data, the queries and the scoring.
  • There are no joins. The README itself says classical warehouses built around star or snowflake schemas may be at a disadvantage. Tiger Data built RTABench, with a normalised schema and selective queries, on ClickBench’s scripts for exactly this reason.
  • 100 million rows is small by the README’s own words: the whole table fits in RAM on many single machines, and most results are single-node. It tells you little about multi-terabyte data, clusters or many users at once: queries run one at a time, and the concurrent-load test added in 2026 isn’t shown in the score.
  • Defaults are expected, but tuning is allowed if the entry is labelled (for example pinot-tuned) and shown separately; pre-aggregated tables, projections and materialized views are out of competition, and extra indexes are discouraged. Engines also improve against the benchmark over time: the README lists issues and fixes in DuckDB, TimescaleDB, Databend, QuestDB and others that came out of ClickBench runs, and Databend says it runs ClickBench in its CI.
  • Cold runs aren’t equal. Managed services such as ClickHouse Cloud, Databricks, MotherDuck and Hologres clear nothing before the first run and are tagged no-cold. Their hardware also differs from the c6a.4xlarge, so compare only entries on the same machine.
  • Vendors and projects quote their rank in announcements, such as Databend’s 2023 post and DataFusion’s 2024 claim to be the fastest single-node engine for Parquet. The README allows such scoreboards but doesn’t encourage them, and a rank changes with the machine, metric and filters picked.
  • Some licences forbid publishing results. Vertica, kdb (KDB-X Community Edition), DolphinDB and Deepgreen have scripts in the repository but no published numbers.

Systems it covers that have a page here

Alibaba Cloud HologresCommercialAlibaba Cloud’s PostgreSQL-compatible real-time data warehouse, which takes streaming writes, answers analytical queries and serves key lookups from one copy of the data.Amazon AthenaAWSAWS’s serverless SQL engine for data in S3: no cluster to run, and on-demand queries cost $5 per TB scanned.Apache DataFusionOpen sourceA query engine library in Rust, built on Arrow, that other projects embed and extend to build their own databases and data tools.Apache DruidOpen sourceAn open-source real-time analytics database that makes Kafka and Kinesis events queryable within seconds and serves fast slice-and-dice queries to dashboards and APIs.Apache HiveOpen sourceThe first SQL engine for Hadoop, and the source of the Hive Metastore, the table catalog that Trino, Spark, Impala and Flink still read.Apache ImpalaOpen sourceAn MPP SQL engine in C++ for interactive queries over Hive tables on HDFS, Kudu, Iceberg and object storage; built and mainly sold by Cloudera.Apache SparkOpen sourceThe general-purpose distributed engine for large batch jobs, streaming and machine learning, in Python, SQL, Scala, Java or R.ArcOpen sourceA young single-binary time-series database in Go that writes incoming data as Parquet files and queries them with DuckDB SQL.CedarDBCommercialA PostgreSQL-compatible database rebuilt from scratch at TU Munich, running transactions and analytics on one copy of the data on a single server.chDBOpen sourceThe ClickHouse engine packaged as a library: run ClickHouse SQL inside a Python, Go, Rust or Node.js program, with no server.ClickHouseOpen sourceAn open-source column-oriented database for real-time analytics, fast enough to serve dashboards over billions of rows.CockroachDBCommercialA distributed SQL database that speaks the PostgreSQL wire protocol, replicates every slice of data with Raft and keeps transactions serializable across nodes and regions.DatabricksCommercialA managed lakehouse platform built on Apache Spark and Delta Lake, with Unity Catalog for governance, on AWS, Azure or Google Cloud.DuckDBOpen sourceAn in-process analytical SQL database: a library with no server that queries Parquet, CSV, Iceberg and S3 directly.FireboltCommercialA cloud data warehouse built for low-latency, high-concurrency queries behind apps and dashboards, also free to self-host as Firebolt Core.GizmoSQLOpen sourceA database server that wraps DuckDB (or SQLite) and serves it to many clients over Arrow Flight SQL, with TLS and authentication.Google BigQueryGoogle CloudGoogle Cloud’s serverless data warehouse: no clusters, and you pay per TiB scanned or per slot-hour.MongoDBCommercialA document database that stores JSON-like records with a flexible schema, from one replica set to a sharded cluster.MotherDuckCommercialA serverless cloud data warehouse built on DuckDB, where one query can run partly on your laptop and partly in the cloud.MySQLOpen sourceThe long-standing open-source SQL database behind much of the web, built on the InnoDB engine.PivotOpen sourceA young open-source analytics server in Rust that speaks the PostgreSQL protocol and queries Iceberg and Delta Lake tables straight from object storage.PostgreSQLOpen sourceThe open-source relational database that most new projects start on, extensible enough to grow into many niches.Presto (PrestoDB)Open sourceFacebook’s distributed SQL engine, now governed by the Linux Foundation, moving its workers from Java to C++ on Velox. Trino is its 2019 fork.QuestDBOpen sourceA columnar time-series database in Java, C++ and Rust that ingests millions of rows a second and answers time-series SQL, with old partitions kept as Parquet.RayforceOpen sourceA small embeddable engine in pure C that runs columnar analytics, graph traversals and recursive Datalog queries in one optimised plan.ScramDBCommercialA brand-new, closed-source database that speaks the PostgreSQL protocol and promises transactions, analytics and vector search on one copy of the data; first builds shipped in summer 2026.SnowflakeCommercialA fully managed cloud data warehouse that separates storage from compute, with virtual warehouses billed per second.SQLiteOpen sourceA complete SQL database in a library and a single file, with no server to run.TDengineOpen sourceA clustered time-series database for IoT and industrial data that gives every device its own table, grouped under “supertables” with tags.TimescaleDBOpen sourceA PostgreSQL extension that turns ordinary tables into time-partitioned, compressed time-series tables.TinybirdCommercialA hosted ClickHouse platform that turns SQL queries into authenticated REST API endpoints, for analytics inside your product.TrinoOpen sourceA distributed SQL engine that queries data where it lives, from Iceberg tables on S3 to a live PostgreSQL database, in one query.

In depth

How to read the dashboard#

Pick one machine, one metric and the entries that match how you would run the system. The bar is a ratio to the best result, not a time.

SettingWhat it showsWatch for
Hot runBest of the second and third run of each query, with data in cachesClosest to a dashboard querying warm data; systems that keep everything in memory look best here
Cold runFirst run, after a restart and a dropped page cacheEntries tagged no-cold only dropped the OS cache, or nothing; in-memory systems are left out of this view and of Combined
Load timeSeconds to load the datasetZero for stateless engines that query the Parquet files where they are
Data sizeBytes on disk, including indexes and logsCan’t be measured for in-memory systems
CombinedWeighted mix: load 10%, size 10%, cold 20%, hot 60%The default since September 2025; pick a single metric if you care about one
×1.00, ×2.00, …Geometric mean of per-query ratios to the fastest entryA failed query costs twice the entry’s slowest time (at least 600 s), which drags the score down hard
FiltersMachine, open source or not, tuned or not, CPU or GPU, and storage kind (native, cloud, memory, Parquet, data lake, web)Deselect the queries that don’t match your workload; the dashboard recomputes the score
  • Each result file carries its run date; old entries (Druid’s is from July 2022) may not reflect current versions.

Sources · facts checked 2026-10-06

Improve this page on GitHub