. -->

Building ClickCannon - a tool for benchmarking ClickHouse | ClickHouse<br>Skip to content

Open searchOpen region selectorEnglish<br>Japanese<br>Korean<br>Chinese<br>French<br>Spanish<br>Portuguese<br>Arabic

48.9kSign inGet Started

->Scroll to top<br>BackBlog<br>Engineering<br>Copy pageCopied!More actionsView as Markdown Open this page in Markdown<br>Open in ChatGPT Ask questions about this page<br>Open in Claude Ask questions about this page<br>Open in v0 Ask questions about this page

Building ClickCannon - a tool for benchmarking ClickHouse

Spencer Torres<br>Jun 11, 2026 · 22 minutes read

TL;DR; #

Today, we're announcing ClickCannon, an open-source benchmarking tool for ClickHouse. What began as an internal project to benchmark observability workloads and build sizing recommendations for ClickStack evolved into a generic framework for replaying data, simulating users, and measuring workload performance at scale. In this post, we'll cover:

The challenges of benchmarking realistic observability workloads

How we replay real production data at controlled throughput

The concurrency architecture that enables high-throughput workload generation

How we simulate realistic user behavior and query patterns

How we collect, analyze, and compare benchmark results

Find ClickCannon at https://github.com/ClickHouse/ClickCannon.

Intro #

As ClickStack adoption has grown over the past year, one question kept coming up:

How much hardware do I need to run ClickHouse?

Whether users are running Managed ClickStack or deploying the open-source stack themselves, they want to know how much CPU, memory, and disk are required to handle their observability workload.

Answering that question required us to build a sizing model, which in turn became a benchmarking exercise. We needed to understand how different schemas, ingestion rates, query patterns, and hardware configurations behaved under realistic observability workloads.

Existing tools helped with parts of the problem, but none gave us the level of control we needed over both inserts and queries. What started as an internal tool for sizing observability deployments eventually grew into something much more flexible.

As the project evolved, we realized we weren’t just building a benchmarking framework for observability. We had inadvertently built a generic workload testing tool for ClickHouse.

The same primitives that allowed us to replay OpenTelemetry data, simulate users, and measure performance at scale could be applied to almost any insert and query workload. That’s why we’ve decided to open-source it.

Today, we’re pleased to announce ClickCannon, a generic benchmarking tool for ClickHouse that allows you to benchmark custom insert and query workloads with fine-grained control over throughput, concurrency, and user behavior.

The challenges of benchmarking observability #

How do you go about benchmarking observability? The performance of an observability system is shaped by the interaction between the table schema, the rate at which data is ingested, and the query workload generated by users.

Any sizing model, therefore, needs a way to capture these variables. We’ll begin with ingest throughput, as it is one of the most important inputs and often the easiest for users to estimate.

Benchmarking inserts #

We measure throughput as uncompressed throughput because it’s the metric most observability users already understand when sizing workloads or migrating from other platforms, and it avoids the variability introduced by different compression algorithms, transfer formats, and data characteristics.

Most observability workloads have a relatively steady stream of incoming data with occasional spikes, alongside users continuously searching logs, filtering traces, and exploring recent events.

The primary challenge here is sustaining ingest throughput to reproduce a specific workload size. Let’s say you wanted to hit 100 MiB/s of uncompressed throughput for a given hardware configuration. We’re not looking for 50 MiB/s nor 200 MiB/s, it needs to be as close to 100 MiB/s as possible. Then you need to repeat it for 1 GiB/s, and then up to 5 GiB/s (or about 12.3 PiB/month) of controlled throughput.

Benchmarking queries #

At the same time, observability is a real-time problem. Data is continuously ingested as users query recent events, filter traces, inspect logs, and jump between time ranges. A useful benchmark, therefore, cannot just measure inserts in isolation. It needs to simulate realistic query workloads while data is still arriving, allowing us to model different levels of user activity and concurrency alongside ingestion.

The underlying ClickHouse schema can also be tuned and optimized in different ways, with each choice affecting storage, ingest, and query performance. We'll discuss this problem in the second part of this blog post, where we used ClickCannon to optimize the default ClickStack schema.

Using representative data and choosing formats #

Before we could benchmark anything, we...