Benchmark and comparison: QuestDB vs. ClickHouse

last updated March 18, 2026 Benchmarks for ClickHouse 26.2.4.23 and QuestDB 9.3.3.

In this article:

• Two databases, different strengths
• Performance benchmarks
• Architecture
• Openness and data formats
• ClickHouse limitations
• QuestDB limitations
• Conclusion

Two databases, different strengths

QuestDB and ClickHouse are both fast analytical databases, but they come from different worlds and solve different problems.

QuestDB is built for high-throughput streaming ingestion and low-latency queries. It works efficiently at any batch size, from single rows to large batches, and sits on the critical path for some of the fastest markets out there: capital markets, trading, defense, energy, and now robotics. It was conceived on low-latency trading floors in the most demanding desks such as eFX at tier-1 investment banks. It is lightweight and designed to work out of the box. Written in zero-GC Java and C++, licensed under Apache 2.0. The enterprise edition adds a Rust-based infrastructure layer for high availability and elastic scaling.

ClickHouse is an OLAP engine with a wider range of use cases. It started at Yandex for e-commerce and ad tech analytics, and its SQL primitives reflect that heritage. Today it powers log monitoring, observability, and product analytics, with a growing ecosystem that positions it as an alternative to tools like Datadog and as a destination for data coming out of OLTP systems like Postgres. Streaming ingestion is not its key strength; ClickHouse is more optimized for batch loading and has been moving toward the standard warehousing model in the vein of Snowflake. Written in C++, also Apache 2.0.

The two databases don't compete head-to-head on most workloads. That said, it is natural for engineering teams to evaluate both when looking for a fast analytical engine, so this article provides a fair comparison on performance, architecture, and ease of use.

Performance benchmarks

Summary (TSBS benchmark): QuestDB is 4.1-4.8x faster on ingestion and 27x faster on lastpoint queries. For analytical queries, QuestDB is 3.4-4.9x faster on short-range point lookups and 1.3x faster on heavy scans, while ClickHouse is 2.1x-2.3x faster on 12-hour range queries and 1.2x faster on some double-groupby aggregations.

We use the open-source Time Series Benchmark Suite (TSBS) for all benchmarks, which supports both ClickHouse and QuestDB out of the box.

Hardware: AWS EC2 r8a.8xlarge (32 vCPU, 256 GB RAM, AMD EPYC), GP3 EBS storage (20,000 IOPS, 1 GB/s throughput)

Software: Ubuntu 22.04, ClickHouse 26.2.4.23, QuestDB 9.3.3 - all with default configurations

Ingestion benchmark

We test a cpu-only scenario with two days of CPU data for various numbers of simulated hosts (100, 1K, 4K, 100K, and 1M). This tests how each database handles increasing data volumes and cardinality.

In time-series databases, high cardinality means having many unique values in indexed columns (millions of unique symbols, account IDs, or trading venues). More hosts in this benchmark means higher cardinality.

Commands to generate and ingest data for 4K hosts at 10s intervals:

$ ./tsbs_generate_data --use-case="cpu-only" --seed=123 --scale=4000 \
    --timestamp-start="2016-01-01T00:00:00Z" \
    --timestamp-end="2016-01-03T00:00:00Z" \
    --log-interval="10s" --format="clickhouse" > /tmp/clickhouse_data

$ ./tsbs_load_clickhouse --db-name=benchmark --file=/tmp/clickhouse_data \
    --host=localhost --workers=32

The results for ingestion with 32 workers:

Key observations:

• QuestDB is 4.1x to 4.8x faster than ClickHouse across all cardinality levels
• ClickHouse holds steady at ~1.74M rows/sec regardless of cardinality
• QuestDB delivers 7-8.6M rows/sec, peaking at 8.59M rows/sec at 100K hosts
• QuestDB's WAL-based architecture avoids merge overhead during ingestion
• ClickHouse can reach higher throughput with tuning (parallel threads, block sizes, async inserts), but that requires configuration work. QuestDB hits these numbers with defaults

Query performance

Ingestion is only half the story. Here are the query benchmarks from the standard TSBS suite:

• single-groupby: Aggregate CPU metrics for random hosts over specified time ranges
• double-groupby: Aggregate across ALL hosts, grouped by host and time intervals
• high-cpu: Finding hosts with CPU utilization above threshold (single host and all hosts)
• lastpoint: Retrieving the most recent data point per host
• groupby-orderby-limit: Top-N aggregation with ordering

All queries target two days of 4000 emulated host data.

To run the benchmark:

$ ./tsbs_generate_queries --use-case="devops" --seed=123 --scale=4000 \
    --timestamp-start="2016-01-01T00:00:00Z" \
    --timestamp-end="2016-01-03T00:00:00Z" \
    --queries=1000 --query-type="single-groupby-1-1-1" \
    --format="clickhouse" > /tmp/clickhouse_query

$ ./tsbs_run_queries_clickhouse --file=/tmp/clickhouse_query \
    --db-name=benchmark --workers=1

Single-groupby queries

Double-groupby queries

These queries aggregate across ALL hosts, grouped by host and 1-hour intervals.

Heavy queries

Finding hosts with CPU utilization above threshold.

Lastpoint and additional queries

The lastpoint query retrieves the most recent data point per host, one of the most common time-series operations. QuestDB's LATEST ON syntax is purpose-built for this pattern and completes in 1.56ms vs ClickHouse's 41.79ms. The groupby-orderby-limit query tests top-N aggregation, where QuestDB holds a slight edge.

Why these differences?

Both are columnar databases, but they make different architectural trade-offs that explain these results:

Why QuestDB wins on ingestion and point queries:

• Designated timestamp lets QuestDB prune time ranges without scanning
• JIT compilation compiles query filters to machine code at runtime
• Time-partitioned storage organizes data physically by time, which matches how time-series queries actually access data

Where ClickHouse architecture pays off:

• Flexible sorting via MergeTree's ORDER BY can optimize for non-time-based access patterns
• Distributed queries with native sharding for horizontal scalability
• Observability stack with native JSON type, inverted indices for text search, and OpenTelemetry integration

ClickBench: Web analytics workload

ClickBench is a benchmark maintained by ClickHouse that tests analytical query performance on web analytics data (hits from Yandex.Metrica). This is a different workload than TSBS and plays to ClickHouse's strengths: wide tables and string-heavy analytics.

Hardware: QuestDB on AWS c7a.metal-48xl, ClickHouse on both c8g.metal-48xl and c7a.metal-48xl

The results below show hot run performance, where data is already cached in memory. Note that the default view on the ClickBench website shows combined results. Select "Hot Run" to see this view.

Architecture

How data is stored

ClickHouse uses the MergeTree engine. Data is written to immutable parts (one compressed file per column + sparse index), which are continuously merged in the background. You define the sort order via ORDER BY, and rows within each part are physically sorted by that key.

CREATE TABLE trades (
    timestamp DateTime64(6),
    symbol String,
    exchange String,
    side String,
    price Float64,
    quantity Float64,
    trade_id UInt64
) ENGINE = MergeTree()
ORDER BY (symbol, timestamp);

QuestDB uses a three-tier architecture: a write-ahead log (WAL) for durability and out-of-order handling, time-partitioned columnar files for query performance, and optional Parquet cold storage on S3/Azure/GCS. No background merges needed.

CREATE TABLE trades (
    timestamp TIMESTAMP,
    symbol SYMBOL,
    exchange SYMBOL,
    side SYMBOL,
    price DOUBLE,
    quantity DOUBLE,
    trade_id LONG
) TIMESTAMP(timestamp) PARTITION BY DAY;

The key difference: ClickHouse's MergeTree requires background merges to consolidate parts, which compete with queries for resources. QuestDB's WAL writes directly to time-partitioned columnar storage, giving predictable write latency even under heavy load.

SQL and ecosystem

Both use SQL. ClickHouse has its own dialect; QuestDB extends standard SQL with time-series primitives. Here are two examples of QuestDB queries:

-- Hourly OHLCV bars for yesterday
SELECT timestamp, symbol, sum(quantity) AS volume, avg(price) AS avg_price
FROM trades
WHERE timestamp IN '$yesterday'
SAMPLE BY 1h;

-- Markout analysis: mid-price evolution
-- at 1s, 5s, 30s, 1m, 5m after each trade
SELECT t.symbol, h.offset, avg(q.mid - t.price) AS markout
FROM trades t
HORIZON JOIN quotes q ON (t.symbol = q.symbol)
    LIST (1s, 5s, 30s, 1m, 5m) AS h
WHERE t.timestamp IN '$today#XNYS'
GROUP BY t.symbol, h.offset;

Both databases have broad ecosystem support (Grafana, Kafka, all major client libraries, dbt). QuestDB speaks the PostgreSQL wire protocol, so any PG client library works out of the box. ClickHouse has a more mature ecosystem with a wider variety of table engines and community tooling.

Openness and data formats

QuestDB writes cold data to Apache Parquet on S3, Azure Blob, or GCS. Any tool that reads Parquet (DuckDB, Spark, Trino, pandas) can query it directly, with no QuestDB instance required. Your data stays yours in open formats, queryable across tiers.

ClickHouse stores all data in its proprietary MergeTree columnar format, including cold storage on S3. When ClickHouse tiers data to object storage, it remains in MergeTree format, not Parquet or any other open standard. That data is opaque to everything except ClickHouse. To export it, you need a running ClickHouse instance to do the conversion. It's also worth noting that ClickHouse's cloud-native engine (SharedMergeTree) is closed-source and only available on ClickHouse Cloud, widening the gap between the open-source and proprietary versions.

ClickHouse limitations

Not optimized for streaming ingestion and low-latency queries

ClickHouse is built for batch loading. Streaming single rows or small batches is not where it shines, and the MergeTree architecture adds overhead: incoming data creates small immutable parts that must be merged in the background, competing with queries for resources. Deduplication in particular has a significant impact on ingest performance compared to QuestDB's WAL-based approach, which handles deduplication natively during the commit phase.

Lacking primitives for time-series analysis

ClickHouse has no equivalent to SAMPLE BY, LATEST ON, WINDOW JOIN, HORIZON JOIN, or TICK syntax. Some of these can be approximated with verbose workarounds (explicit GROUP BY toStartOfInterval(...), subqueries, self-joins), but others like multi-offset markout analysis with HORIZON JOIN are simply not possible in ClickHouse.

Even where workarounds exist, performance is the real gap. QuestDB's ASOF JOIN uses six different algorithms under the hood and selects the optimal one based on data distribution. HORIZON JOIN computes markout analysis at multiple time offsets in a single pass. LATEST ON completes in 1.56ms where ClickHouse needs 41ms (27x slower). These are not ergonomic differences; they are performance differences on the workloads that matter for capital markets and real-time analytics.

Hard to operate at scale

ClickHouse's MergeTree architecture requires careful tuning: part management (the default limit of 300 parts per partition requires monitoring), merge scheduling (background merges compete with queries for CPU), and ORDER BY selection (choosing the wrong primary key order significantly impacts performance, and changing it means recreating the table). ClickHouse Cloud addresses this with a fully managed offering, but self-hosted ClickHouse remains operationally demanding.

QuestDB limitations

Narrower scope by design

QuestDB is purpose-built for time-series and financial data workloads. If you need a general-purpose OLAP engine for product analytics, log search, or ad-hoc BI across semi-structured data, ClickHouse covers more ground.

Younger ecosystem

ClickHouse has been open-source since 2016, QuestDB since 2019. That three-year head start shows in the number of third-party integrations, community tooling, and resources available.

Conclusion

Choose QuestDB where speed is mission critical. Capital markets, trading, crypto, defense, energy, and robotics teams choose QuestDB for streaming ingestion, low-latency queries, and time-series SQL primitives. Data flows in fast and flows out to an open lakehouse (Parquet on S3) with no lock-in.

Choose ClickHouse for observability (logs, traces, metrics), product analytics, semi-structured JSON data, or general OLAP workloads where you want a managed cloud service and a broad ecosystem.

Ready to try QuestDB? Get started with the quickstart guide or join our Slack community to ask questions.

More database comparisons

• QuestDB vs. InfluxDB
• QuestDB vs. InfluxDB 3
• QuestDB vs. TimescaleDB