ClickHouse for Observability in 2026: ClickStack, SigNoz, 431 PiB of Logs

Every few months someone asks me which observability backend to self-host, and for the last two years my answer has quietly converged on the same database underneath. Not the same product, the same storage engine. ClickHouse for observability has gone from a niche choice at companies like Uber to the default substrate of the open-source alternatives to Datadog: SigNoz runs on it, Uptrace runs on it, and ClickHouse Inc. bought HyperDX and now ships its own stack, ClickStack. This post explains why columnar storage won logs and traces, how the three main ClickHouse-based stacks differ in late 2026, what the cost comparison with Datadog and Elasticsearch actually looks like when you do the arithmetic, and where ClickHouse is still the wrong tool.

Why did columnar storage win logs and traces?

A log line or a span is a wide, sparse row: a timestamp, a service name, a severity, a trace ID, a body, and a bag of attributes that varies by service. The questions you ask of that data are mostly aggregations over a few columns (error rate by service over the last hour, p99 latency by endpoint) plus the occasional needle search for one trace ID or one string.

Elasticsearch was built for the needle. It maintains an inverted index over every indexed field, which makes arbitrary text search fast and makes ingestion and storage expensive. Uber's 2021 write-up of its move from ELK to ClickHouse, Fast and Reliable Schema-Agnostic Log Analytics Platform, is still the clearest statement of the problem: it ran more than 20 Elasticsearch clusters per region, limited indexing to fields three levels deep, and still found that ingesting all its logs was too expensive to scale, against a goal of handling 10x growth. In ClickHouse it saw compression of 3x, and up to 30x in some cases.

A columnar engine stores each column separately, sorted by a primary key you choose (usually service and time). Repeated values like service.name or severity_text compress to almost nothing, and an aggregation only reads the columns it touches. ClickHouse's own internal logging platform, LogHouse, is the best public evidence of what that buys at scale. The first LogHouse post in March 2024 reported 19 PiB uncompressed stored as about 1.13 PiB, roughly 17x. The June 2026 follow-up reports 431 PiB uncompressed across 1.59 quadrillion rows, held in 27 PiB on disk, about 16x, with typical queries returning in a few hundred milliseconds.

Elastic has not stood still. Its logsdb index mode, generally available from 8.17, claims up to 65% less storage by sorting indices and using ZSTD, delta and run-length encoding, which is to say by borrowing columnar techniques. Elastic later reported a further 16% storage reduction in 8.19 and 9.1. The catch is licensing: synthetic _source, a large part of the saving, needs an Enterprise licence or Serverless. The gap has narrowed, but a 65% saving is about 2.9x, not 16x.

If you want the conceptual background on what you are storing, my observability vs monitoring explainer covers the signals, and distributed tracing explained covers the span model these stores are built around.

What is ClickStack, and what did ClickHouse buy?

On 13 March 2025 ClickHouse announced it had acquired HyperDX, an open-source observability UI that already used ClickHouse as its store. The product that followed is ClickStack, which ClickHouse describes as three parts: an opinionated distribution of the OpenTelemetry Collector, ClickHouse itself, and HyperDX as the interface. ClickStack entered private preview in ClickHouse Cloud on 6 August 2025, and the same page now notes that Managed ClickStack is in beta. The repository moved to ClickHouse/ClickStack under the MIT licence; the latest app release when I checked was 2.43.1 on 1 November 2026.

The company behind it has money to spend on this. On 16 January 2026 ClickHouse closed a $400 million Series D led by Dragoneer, reported by SiliconANGLE at a valuation of about $15 billion, and in the same announcement bought Langfuse, the open-source LLM observability platform. So ClickHouse now owns a general observability UI and an LLM tracing tool, both sitting on its own database. That is a coherent strategy, and also a reason to think about vendor concentration before you standardise on it.

OpenAI is the reference customer everyone cites. ClickHouse's June 2025 case study says OpenAI ingests petabytes of logs per day on a 90-shard cluster with two replicas each, and that about 80% of queries touch only the last two days of data, which is why older data moves to blob storage. That last number matters more than the petabytes: observability queries are heavily skewed to recent data, which is exactly what tiered columnar storage is good at.

SigNoz vs ClickStack vs Uptrace: which ClickHouse stack?

All three accept OpenTelemetry natively and store in ClickHouse. They differ in licence, scope and how much of the database they expose.

	SigNoz	ClickStack (HyperDX)	Uptrace
Latest release (checked 10 Nov 2026)	v0.149.0, 4 Nov 2026	app 2.43.1, 1 Nov 2026	v2.0.3 stable, v2.1.0-rc.2
Licence	MIT outside ee/ and cmd/enterprise/ (LICENSE)	MIT	AGPL-3.0
Storage	ClickHouse plus Postgres or SQLite metadata	ClickHouse	ClickHouse plus Postgres metadata (README)
Self-host install	Foundry CLI (Compose, Helm, systemd, ECS)	all-in-one Docker image or Helm	Docker Compose example in repo
Query style	builder, PromQL, ClickHouse SQL	Lucene-style search and SQL	builder, PromQL, ClickHouse SQL
Managed price	$0.30/GB logs and traces, $0.10 per million metric samples, $49 base (pricing)	via ClickHouse Cloud	Uptrace Cloud

SigNoz is the most complete APM replacement: service maps, exceptions, alerts with routing, dashboards, and LLM token cost attribution in its collector. Its install changed in 2026. The v0.130.0 release on 23 June deprecated the old install.sh and Compose files in favour of Foundry, a CLI that generates manifests from one casting.yaml. The new default stack uses ClickHouse Keeper instead of ZooKeeper and Postgres instead of SQLite for metadata. I walk through it in the companion guide, How to Self-Host SigNoz with OpenTelemetry.

ClickStack is the thinnest layer over ClickHouse and the one most likely to suit a team that already runs ClickHouse for analytics and wants observability data next to business data. Uptrace is smaller and AGPL, which is fine for internal use but worth a conversation with legal if you plan to embed or resell it.

How much cheaper is ClickHouse than Datadog?

List prices first, because they are the only numbers anyone can check. From Datadog's pricing list, billed annually: log ingestion is $0.10 per GB, and indexing with 15-day retention is $1.70 per million events ($2.50 for 30 days). APM is $31 per host, with indexed spans at the same per-million rates.

Take a modest workload: 500 GB of logs a day, 15,000 GB a month, at an assumed average of 1 KB per event, so about 15 billion events a month.

Option	Monthly cost for 500 GB/day, 15-day retention	Basis
Datadog, ingest plus 15-day index	$27,000 ($1,500 ingest + $25,500 index)	Datadog list, annual
SigNoz Cloud	$4,500	$0.30/GB
Self-hosted ClickHouse, disk only	about $75 (7.5 TB raw / 16x, two replicas, gp3)	LogHouse ratio, EBS $0.08/GB-month

The self-hosted line is deliberately incomplete. It excludes compute, which dominates, plus Keeper, backups, network, and the engineer who gets paged when merges fall behind. Even so the gap is not subtle. ClickHouse's own LogHouse comparison put its workload at about $150,000 a month on ClickHouse Cloud list price against a projected $26 million a month on Datadog list price, "at least 200x" cheaper. That is a vendor comparing itself with a competitor at list price, at a scale where nobody pays list, so treat it as an upper bound. My broader Grafana vs Datadog vs New Relic cost comparison has more worked scenarios.

The honest summary is that the per-GB price of a ClickHouse-backed SaaS is roughly a sixth of an indexed-log SaaS, and self-hosting moves the bill from storage to people. Whether that is a saving depends on whether you already have people who operate stateful systems.

How do you check what ClickHouse is actually storing?

The first thing I do on any ClickHouse-backed stack is look at compression per table, because the ratio tells you whether your schema and sort key are doing their job. This runs against any ClickHouse 25.x server, including the one inside SigNoz (signoz_logs, signoz_traces) or ClickStack (otel_logs, otel_traces in the default database).

-- ClickHouse 25.12: compressed vs raw size per observability table
SELECT
    database,
    table,
    formatReadableSize(sum(data_compressed_bytes))   AS on_disk,
    formatReadableSize(sum(data_uncompressed_bytes)) AS raw,
    round(sum(data_uncompressed_bytes) / sum(data_compressed_bytes), 1) AS ratio,
    sum(rows) AS rows
FROM system.parts
WHERE active
  AND database IN ('signoz_logs', 'signoz_traces', 'default')
GROUP BY database, table
ORDER BY sum(data_compressed_bytes) DESC
LIMIT 10;

If logs compress at 3x rather than 10x or more, the usual culprits are unique IDs in high-volume attributes, bodies that are serialised JSON with random key order, or a sort key that scatters a service's rows across parts.

Where is ClickHouse the wrong choice for observability?

It is not free of trade-offs, and the vendors are understandably quiet about them.

Operations. ClickHouse is a distributed database with replication, a coordination service (Keeper or ZooKeeper), background merges and schema migrations. Too many small inserts produce too many parts; a stuck merge or full disk stops ingestion. If nobody on your team wants to own that, buy the managed version. Kubernetes makes it easier to run but not easier to understand, as I argued in running databases on Kubernetes.

Schema changes are real migrations. SigNoz v0.149.0's release notes warn that log bodies are moving to native JSON storage and that logs are now dual-ingested, which needs extra collector CPU and memory, ClickHouse CPU and log disk. That is the right long-term move and a capacity event you have to plan, not a routine upgrade.

Needle searches. Finding one string across 30 days of unstructured bodies is still where an inverted index shines. ClickHouse has skip indexes and Bloom filters (OpenAI's case study credits a Bloom filter change with a 40% CPU drop), and its full-text features keep improving, but if your workflow is mostly grep across free text, test it on your data first.

Metrics. Prometheus-native tooling, recording rules and PromQL ecosystems are deeper than any ClickHouse UI. SigNoz supports PromQL, but many teams keep Prometheus or Mimir for metrics and use ClickHouse for logs and traces. That split is fine.

When should you stay on Elasticsearch, Loki or Datadog?

Stay on Elasticsearch or OpenSearch if search over free text is the primary use, you already run it well, and logsdb's savings close enough of the gap. Choose Loki if your volumes are moderate, your queries are label-scoped, and you live in Grafana; the Loki setup guide covers that path. Stay on Datadog if you are small enough that the bill is less than a fraction of an engineer, or large enough that your negotiated rate bears no resemblance to list price. Everyone else should at least price a ClickHouse-backed option, because the instrumentation is now portable. If you emit OpenTelemetry, as described in my OpenTelemetry and eBPF cost piece, switching backend is a collector exporter change, not a re-instrumentation project.

FAQ

Is SigNoz just ClickHouse with a UI?

No more than Grafana is just Prometheus with a UI. SigNoz ships its own collector distribution with span-metrics, metering and log normalisation processors, a query service, alerting with routing and notification channels, and dashboards. ClickHouse is the storage engine underneath.

Is ClickStack free to self-host?

Yes. The ClickStack repository is MIT-licensed and the all-in-one image runs ClickHouse, the HyperDX UI and a collector in one container for evaluation. Production deployments separate the components, and ClickHouse Cloud sells a managed version.

Why is ClickHouse cheaper than Elasticsearch for logs?

Columnar storage compresses repetitive observability fields far better and only reads the columns a query needs. ClickHouse's LogHouse reports about 16x to 17x compression; Elastic's logsdb claims up to 65% savings over its older format, about 2.9x.

Can I query SigNoz data with SQL?

Yes. SigNoz exposes a ClickHouse SQL query option in dashboards and alerts, and you can connect to its ClickHouse directly for ad-hoc analysis. Treat the schema as internal: it changes between releases, as the 2026 JSON logs migration shows.

If I were choosing this quarter, I would instrument everything with OpenTelemetry first, then run SigNoz or ClickStack side by side with the current vendor for two weeks on a copy of production traffic, using a collector fan-out. I would measure compression on my own data with the query above, price compute honestly, and only then decide whether to self-host or buy the managed version. The database is no longer the hard part; owning it is.

Related: Observability in 2026: OpenTelemetry Graduated, the Collector Is Still v0.162, Grafana vs Datadog vs New Relic Cost 2026 and How to Set Up the OpenTelemetry Collector on Kubernetes (2026).