PromCon EU 2026 · Lightning talk

Prometheus long-term storage on ClickHouse

If you already run ClickHouse, you already run your Prometheus long-term storage. Native support is arriving, and the gaps are small.

This lightning talk at PromCon EU 2026, the Prometheus community conference, is about using ClickHouse as the long-term store behind Prometheus: what ClickHouse now does natively, what it still leaves to you, and how Bleemeo runs it in production. This page sums it up, with the configuration snippets ready to copy and the slides to download.

ClickHouse, a popular analytics database

ClickHouse is a column-oriented database built for real-time analytics: plain SQL over large datasets, with fast scans and high compression. Open source since 2016 under Apache 2.0 and written in C++, it was born at Yandex and is now developed by ClickHouse Inc., self-hosted or as ClickHouse Cloud. Therepository has more than 50,000 GitHub stars and over 2,600 contributors.

Long-term storage, in moving parts

Prometheus keeps a few weeks of data locally. Keeping more means adding a long-term store, and the usual candidates are measured first in the number of services you end up running.

Already running ClickHouse? You already run your long-term storage.

Path 1 — ClickHouse speaks Prometheus natively

ClickHouse ships a TimeSeries table engine that Prometheus can write to and read from directly, and Grafana can query through a Prometheus data source.

-- ClickHouse
SET enable_time_series_table = 1;
CREATE TABLE prometheus.metrics ENGINE = TimeSeries;

<!-- ClickHouse server config: the Prometheus endpoints are off by default -->
<http_handlers>
    <defaults/>
    <rule>
        <url_prefix>/prometheus/api/v1</url_prefix>
        <handler><type>prometheus_api_v1</type></handler>
    </rule>
</http_handlers>

Without this Prometheus handler, ClickHouse answers 404 on /prometheus/api/v1/… — remote write and Grafana both fail. Keep <defaults/>, or the regular SQL and /ping endpoints go away.

# prometheus.yml
remote_write:
  - url: https://ch:8443/prometheus/api/v1/write?database=prometheus&table=metrics

# Grafana: a Prometheus data source pointing at /prometheus

• 24.8 LTS · August 2024 — the TimeSeries table engine lands as experimental, with remote write and remote read.
• 2026 — a PromQL HTTP API: query, query_range, series, labels, metadata. Grafana works unchanged.
• 26.9 · September 2026 — promoted from experimental to private preview (enable_time_series_table). Not generally available yet.

Hot on SSD, warm on HDD, cold on S3

Storage tiering is built into ClickHouse and takes a few lines of configuration. The table stays the same and so do the queries; ClickHouse moves data parts between volumes in the background.

• Hot, on SSD — 0 to 7 days: dashboards and alerting.
• Warm, on HDD — 7 to 90 days: incident investigations.
• Cold, on S3 — beyond 90 days: capacity planning and audits.

TTL timestamp + INTERVAL 7 DAY TO VOLUME 'hdd',
    timestamp + INTERVAL 90 DAY TO VOLUME 's3',
    timestamp + INTERVAL 2 YEAR DELETE
SETTINGS storage_policy = 'hot_warm_cold'

The durations are examples; the storage policy itself is defined in the server configuration.

What SQL adds on top of PromQL

Cardinality forensics

Which metric or label is eating your storage:

SELECT metric_name, count()
FROM timeSeriesTags(prometheus.metrics)
GROUP BY 1 ORDER BY 2 DESC

Join business data

CPU cost per customer, SLA per contract:

SELECT c.name, avg(value)
FROM cpu_usage u
JOIN customers c USING (tenant)

PromQL inside SQL

Filter, join and export the result of a PromQL query:

SELECT * FROM prometheusQuery(prometheus.metrics, 'rate(up[5m])', now())

Path 2 — a thin layer on top

What ClickHouse does not do for you — yet — can be handled by a thin layer in front of it. That is what SquirrelDB, Bleemeo's open-source time series database (Apache 2.0), does on its ClickHouse backend:

• A stable Prometheus API — remote write, remote read and PromQL, while the native engine matures.
• Rollups PromQL uses — 15-minute buckets kept up to date on insert, read automatically by long-range queries.
• Multi-tenancy — tenant isolation, per-series TTL, mutable labels.

Want rollups in pure ClickHouse instead? A MATERIALIZED VIEW into anAggregatingMergeTree, queried in SQL.

In production at Bleemeo

Bleemeo's agents and customers' Prometheus servers remote-write into SquirrelDB, which handles the API, the rollups and the tenants; ClickHouse holds all the storage. It is self-hosted and run by our team, on ReplicatedMergeTree with ClickHouse Keeper.

• 1.5 bytes per point on disk — on par with the Prometheus TSDB.
• A node restarts? Replication catches it up on its own.
• Need to grow? Add a replica; ClickHouse copies the data.

Slides and resources

• PromCon EU 2026 — programme and livestream.
• ClickHouse documentation — Prometheus HTTP API and PromQL.
• github.com/bleemeo/squirreldb — multi-tenancy and PromQL rollups today. See also the ClickHouse backend and the Cassandra-to-ClickHouse migration guides.
• Lionel Porcheron — github.com/lporcheron