A Quadrillion Rows across three Clouds: scaling LogHouse | ClickHouse<br>Skip to content

Open searchOpen region selectorEnglish<br>Japanese

48.4kSign 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

A Quadrillion Rows across three Clouds: scaling LogHouse

Sergey Veletskiy<br>Jun 30, 2026 · 22 minutes read

LogHouse, our internal logging platform for ClickHouse Cloud, now stores 431 PiB of uncompressed data across 1.59 quadrillion rows . It spans 30+ regions across three cloud providers, and a typical query against any of them comes back in a few hundred milliseconds.

This is the third post in a series. In the first, we built LogHouse and replaced Datadog, at 19 PiB. In the second, we crossed 100 PB and introduced SysEx, our purpose-built pipeline for system-table telemetry that now sits alongside OpenTelemetry in our stack. Together, the three posts trace a steep curve: 19 PiB → 431 PiB, a 23x jump in two years, and 37 trillion → 1.59 quadrillion rows.

Introduction #

Two years ago, the architecture was simple: one ClickHouse instance per region, and whoever needed logs connected to that region directly. That was fine at 19 PiB on a handful of AWS regions. It doesn't hold at 431 PiB across 30+.

The pressure came from the write path first. As ClickHouse Cloud has grown, so has the volume of data flowing through it, reaching peaks of 80 GiB/s and 190 million rows per second . To keep pace, the write path needed to do two things well: scale horizontally and remain reliable while doing it.

The answer to the first challenge is geosharding. Writes stay local to the region where they arrive, avoiding cross-region egress costs and allowing each region to scale independently. As demand grows, busy regions can have multiple cells, providing near-linear scaling without affecting the rest of the system.

The catch is that while geosharding is a write-side decision, it incurs a read-side bill. Even with one cell per region, the per-region data source model was already awkward to manage and to use. Cells would have made it untenable. We weren't willing to push that complexity onto the people querying LogHouse.

So we set out to reconcile the two sides: let writes split as freely as we want, while making reads behave as if the topology underneath didn't exist. The rest of this post is about how we did that: first, the write path; then the read layer that makes cell creation transparent; and finally, the scaling limits we’re beginning to run into next.

The numbers: A quadrillion rows #

Today, LogHouse stores 431 PiB of uncompressed data across 1.59 quadrillion rows (1.59 × 10¹⁵) . That's roughly a 23x increase from where we were two years ago.

SystemUncompressed SizeRowsSysEx335 PiB1.48 quadrillionOTel95 PiB109 trillionTotal431 PiB1.59 quadrillion

SysEx (responsible for exporting ClickHouse system tables) accounts for 78% of the volume and 93% of the rows, which is a clear validation of the architectural bet we described in our previous post. OpenTelemetry continues to handle stdout/stderr collection at info-level and above, serving as a safety net for crash-looping services where SysEx can't scrape system tables.

All 431 PiB compresses down to 27 PiB on disk, for roughly a 16x compression ratio - consistent with what we've seen since the early days of LogHouse. Most tables are retained for 180 days , with many SysEx tables kept for up to 365 days , giving LogHouse users a long window for investigations and historical analysis.

What's driving the growth #

We have added new data sources since our last post: OTel traces, Kubernetes object history, and additional system tables via SysEx. But the main driver of growth is simpler than any of that. It's just that ClickHouse Cloud keeps growing. More customers means more clusters, which means more logs and events, more query history, and more system telemetry. The data volume scales roughly linearly with the number of clusters we operate.

The infrastructure behind it #

LogHouse now runs on 33 geoshards (36 cells in total) across three cloud providers, with each cell a separate ClickHouse Cloud instance. Most geoshards consist of a single cell, but our busiest regions have multiple cells.

At peak, the system ingests:

80 GiB/s of uncompressed data

190 million rows per second

across ~5,800 inserts per second

Our busiest single cell handles 21 GiB/s, 61 million rows per second, and 620 inserts per second at peak.

Why we created cells #

The first is blast radius. When something goes wrong with a cell (ClickHouse cluster), only the logs flowing through it are affected. The rest of the region keeps writing and reading normally. With a single cell per region, every operational issue would take out the entire region's visibility.

The second is alignment with the data...