What matters for performance: lessons from a year of benchmarks

nikolay_sivko1 pts0 comments

. -->

What really matters for performance: lessons from a year of benchmarks | 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

What really matters for performance: lessons from a year of benchmarks

Tom Schreiber<br>Dec 22, 2025 · 11 minutes read

Why benchmarks keep showing up in my work #

As the year winds down, I like to zoom out and look at the work I’m proudest of.

I wrote (and helped ship) a lot of ClickHouse content this year, but a bunch of the posts I care about most share the same backbone: each one has a benchmark behind it .

Benchmarks show up again and again in my work because they force clarity. They correct intuition, surface trade-offs, and sometimes overturn narratives that have stuck around for too long.

Here are a few of my favorites from this year, the ones that surprised me, changed how people think about ClickHouse, or directly impacted how real systems were built. Taken together, they form a loose narrative, from data layout and ingestion, through storage and execution, and finally to cost.

And reading back through them, I kept noticing the same thing: performance comes down to how efficiently an engine moves data end-to-end.

The billion-docs JSON benchmark #

This benchmark started with a foundational question: what does JSON look like when you treat it as columnar data instead of a document blob?

ClickHouse completely reimagined JSON storage on top of column-oriented storage, resulting in unmatched speed, compression, and user experience, far beyond any existing JSON data store.

To prove the speed, we created JSONBench: a reproducible benchmark that loads the same real-world dataset (up to 1B Bluesky events) into multiple systems, then measures storage size, cold/hot query runtimes, and data quality (how many documents were successfully ingested).

In the original billion-docs run, ClickHouse was orders of magnitude faster while also being smaller on disk (including 20% more compact than storing the same JSON as compressed files on disk).

We also built a live online dashboard where you can slice results by dataset size, cold vs. hot, storage, and data quality, plus a toggle for systems that flatten JSON.

JSONBench didn’t stop at a blog post. It’s now actively used in the community and regularly receives external pull requests, adding new or updating results for exiting systems.

This is one of my favorite benchmarks this year because the results genuinely surprised me.

ClickHouse was thousands of times faster than traditional JSON data stores like MongoDB, while also using significantly less storage. It completely changed my intuition for what’s possible with analytical queries on JSON.

Side story : ClickHouse already started from a strong lead in the original JSONBench results. We continued improving the JSON implementation independently, and later shipped new shared-data serializations that dramatically improved performance and memory usage for complex JSON workloads. As a result, ClickHouse now leads even further across both cold and hot runs at all dataset sizes, with a significantly larger margin than before.

The input formats benchmark #

This benchmark came from a deceptively simple question: if ClickHouse supports 70+ input formats, which ones actually matter for high-throughput ingestion?

To answer that properly, we built FastFormats, a systematic benchmark that isolates server-side ingestion cost and measures time, CPU usage, memory usage, and file size across dozens of formats, batch sizes, compression schemes, and pre-sorting variants.

The headline result was clear and surprisingly consistent:

Native format wins across essentially all scenarios

Compression (LZ4 first, ZSTD when bandwidth matters) is a no-brainer

Pre-sorting helps , but much less than people expect

Batch size matters more than almost anything else

And, like with JSONBench, we also built a live FastFormats dashboard where you can slice results by format, batch size, compression, pre-sorting, and metric.

This is one of my favorite benchmarks this year because it had direct production impact beyond ClickHouse itself.

Netflix describes how one of their biggest ingestion wins came directly from reading this post and looking at the FastFormats results. After seeing that the native ClickHouse protocol consistently outperformed RowBinary , they reverse-engineered the Go client and implemented native-protocol encoding with LZ4 in their Java pipeline. The result: lower CPU usage, better memory efficiency, and a system that now ingests ~5 PB of logs per day into ClickHouse.

The object storage cache benchmark #

This benchmark started from a practical cloud...

clickhouse json from benchmark year data

Related Articles