Let's Encrypt built its data warehouse with ClickHouse

Let's Encrypt published a technical report on 17 September 2026 detailing how it rebuilt its certificate issuance log analysis pipeline from scratch, moving to a self-hosted ClickHouse-based data warehouse. This matters to anyone operating large-scale log analytics infrastructure: the certificate authority issues between 6 and 10 million certificates per day according to the post, and legacy scripts for generating public statistics (letsencrypt.org/stats) broke regularly.

What changed

According to Let's Encrypt, the team previously used a combination of raw logs and a SaaS log search service, facing rising costs and insufficient performance for analytical workloads. They chose ClickHouse for efficient structured data storage and fast aggregation across large datasets, plus its open source nature.

The hardware

For the new cluster, Let's Encrypt procured three Dell PowerEdge R7715 servers, each with:

Component	Stated specification
CPU	AMD EPYC 9355P, 32 cores, 3.55 GHz
RAM	384 GB
Storage	32 × 3.2 TB NVMe (~100 TB raw per node)

With 100 days of logs and structured data already loaded, stated capacity usage is roughly 14% of total.

Operational results

According to the post, public statistics that previously required hours of processing on compressed files (with multiple failures per year) are now calculated by ClickHouse in under 10 seconds, thanks to materialised views that pre-aggregate issuance data by profile and day. Incident analysis—identifying affected certificates—also shifted from hours of engineering work to minutes of interactive queries.

Challenges encountered

The most critical point, Let's Encrypt writes, was backfilling historical logs: the OTel collector used for real-time ingestion couldn't handle bulk imports (files were silently dropped). The solution was to switch to ClickHouse's native S3 import method, with an S3-compatible gateway in front of the legacy logs, manually aligning parsing rules between the two paths.

For tables subject to recalculation, the team used the ReplacingMergeTree engine, which allows rows to be replaced simply by re-importing them, avoiding surgical deletions. For tables without this engine, they needed to run OPTIMIZE TABLE ... DEDUPLICATE BY, an expensive operation but executed only once.

The full post, with example queries and daily issuance charts, is available on the Let's Encrypt blog.