ClickStack is the open-source observability platform from ClickHouse that combines a columnar database, an OpenTelemetry collector, and the HyperDX frontend into a single stack. It stores logs, traces, metrics, and session replays in one ClickHouse instance and lets you query everything with SQL.
It launched in 2025 after ClickHouse acquired HyperDX, an open-source observability platform that was already built on ClickHouse. The acquisition turned an independent project into an officially supported product backed by the ClickHouse team and its resources.
We deployed ClickStack across local Docker, Helm on Kubernetes, and a production cluster with external ClickHouse. This post explains what it is, how it works, who it is for, and where it fits in the observability landscape.
How ClickStack Came to Exist
The backstory explains why ClickStack is built the way it is.
ClickHouse — originally created at Yandex in 2009, open-sourced in 2016, and now a standalone company valued at $15B — was already being used as the storage engine behind several observability platforms (SigNoz, Uptrace, OpenObserve). ClickHouse noticed a trend: their database was becoming the de facto backend for observability data.
Internally, the ClickHouse team was running their own monitoring on Datadog. When they decided to move off Datadog, they built an internal tool called LogHouse on top of ClickHouse to handle petabyte-scale workloads. During that process, they discovered HyperDX — a small startup founded by Warren and Michael Shi that had built a developer-friendly observability UI on ClickHouse.
In March 2025, ClickHouse acquired HyperDX. HyperDX became the UI layer, the OpenTelemetry Collector became the ingestion layer, and ClickHouse remained the storage and query engine. Together, they became ClickStack.
The result is an opinionated, batteries-included observability platform where every component is designed to work with ClickHouse from the ground up — not bolted on after the fact.
What ClickStack Includes
ClickStack is not a single binary. It is a coordinated set of components that work as one platform.
Core Components
| Component | Role | Technology |
|---|---|---|
| ClickHouse | Storage and query engine for all telemetry data | Columnar OLAP database |
| HyperDX UI | Search, dashboards, alerts, session replay, trace exploration | React-based web application |
| OpenTelemetry Collector | Ingests logs, metrics, and traces via OTLP | Custom-built, pre-configured for ClickHouse |
| MongoDB | Stores application state (dashboards, users, config) | Document database |
The Four Observability Signals
Unlike tools that specialise in one signal type, ClickStack handles all four in one system:
Logs
- Stored in ClickHouse with full-text indexing via
tokenbf_v1 - Searchable using Lucene syntax or SQL
- Correlated with traces through
trace_idandspan_id - Configurable retention (14–30 days typical)
Traces
- Distributed tracing with full span trees
- Delta and ZSTD compression for efficient storage
- Cross-service trace visualisation
- Automatic service maps
Metrics
- Time-series metrics stored in ClickHouse’s columnar format
- Collected via OpenTelemetry or scraped from Prometheus endpoints
- Native support for counters, gauges, and histograms
- 90-day default retention
Session Replays
- Captures frontend user interactions (clicks, navigation, form inputs)
- Links sessions to backend traces and logs
- Enables debugging from “the user clicked checkout” to “the database query failed”
- 7-day retention by default
Session replay is what sets ClickStack apart from most open-source observability tools. You can go from a user reporting “my checkout did not work” to watching what they did, seeing the API call that failed, the trace that shows which service timed out, and the log that explains why — all in one interface.
How Data Flows Through ClickStack
Understanding the data flow helps you make better deployment and instrumentation decisions.
┌─────────────────────────────────────────────────────┐
│ Your Applications │
│ │
│ OTel SDK (traces, metrics, logs) │
│ Browser SDK (session replays, frontend errors) │
└──────────────────────┬────────────────────────────────┘
│ OTLP (gRPC :4317 / HTTP :4318)
▼
┌──────────────────────────────────────────────────────┐
│ OpenTelemetry Collector │
│ │
│ Receivers → Processors → Exporters │
│ (OTLP) (batch, (ClickHouse) │
│ k8sattributes) │
└──────────────────────┬────────────────────────────────┘
│ Batched inserts
▼
┌──────────────────────────────────────────────────────┐
│ ClickHouse │
│ │
│ otel_logs (full-text indexed, partitioned) │
│ otel_traces (compressed, span tree indexed) │
│ otel_metrics (time-series optimised) │
│ otel_sessions (event-based, session correlated) │
└──────────────────────┬────────────────────────────────┘
│ SQL queries
▼
┌──────────────────────────────────────────────────────┐
│ HyperDX UI (:8080) │
│ │
│ Search (Lucene + SQL) │
│ Dashboards & Charts │
│ Alerts │
│ Session Replay Player │
│ Trace Waterfall │
│ Service Map │
└──────────────────────────────────────────────────────┘Ingestion
Applications send telemetry to the OTel Collector using standard OpenTelemetry SDKs — available for Python, Node.js, Java, Go, .NET, Ruby, PHP, Rust, and Elixir. The collector batches data (default: 10,000 items, 2-second timeout) and writes to ClickHouse using optimised inserts.
The collector can also scrape Prometheus /metrics endpoints using the prometheus receiver, which means you can ingest existing Prometheus metrics without changing your exporters.
Storage
Each signal type has its own ClickHouse table with purpose-built schemas:
- Compression — Delta encoding for timestamps, ZSTD for strings and attributes
- Indexing — Bloom filters on trace IDs and attribute keys for fast lookups
- Full-text search — Token-based bloom filters on log bodies
- Partitioning — By date for efficient TTL cleanup and time-range queries
LowCardinality— Dictionary encoding for columns like service name and severity
Querying
HyperDX supports two query modes:
Lucene syntax for quick searches:
error AND service:payment-api AND level:errorSQL for analytical queries:
SELECT ServiceName, count(*) as error_count
FROM otel_logs
WHERE SeverityText = 'ERROR'
AND Timestamp > now() - INTERVAL 1 HOUR
GROUP BY ServiceName
ORDER BY error_count DESCThe power of SQL becomes clear when you correlate across signals:
-- Find traces associated with error logs
SELECT t.TraceId, t.SpanName, t.Duration, l.Body
FROM otel_traces t
JOIN otel_logs l ON t.TraceId = l.TraceId
WHERE l.SeverityText = 'ERROR'
AND l.Timestamp > now() - INTERVAL 30 MINUTE
ORDER BY t.Duration DESC
LIMIT 20This kind of cross-signal query is impossible in traditional stacks where logs, traces, and metrics live in separate databases with different query languages.
Why ClickHouse as the Storage Engine
ClickStack’s performance comes from ClickHouse’s architecture. Understanding why ClickHouse works well for observability explains why ClickStack can offer what it does.
Columnar Storage
Traditional databases store data row by row. ClickHouse stores data column by column. For observability queries — which typically scan one or two columns across millions of rows — columnar storage is dramatically faster because it reads only the columns needed, not entire rows.
Compression
Similar values in a column compress extremely well. Timestamps compress 10–20x with Delta encoding. Low-cardinality columns like service names compress 50–100x. The result: ClickHouse stores observability data at a fraction of the cost of Elasticsearch or purpose-built TSDBs.
Benchmark comparisons show 12–19x better compression than Elasticsearch and 5–30x faster analytical queries.
Vectorized Execution
ClickHouse processes data in batches of thousands of values per CPU cycle, rather than row by row. This makes aggregation queries — the bread and butter of observability — extremely fast even across billions of rows.
Native JSON Support
ClickHouse’s native JSON column type dynamically promotes each path to its own column. This achieves 10x faster searches and 100x less data scanned compared to traditional wide-column approaches. For observability, where log and trace attributes are semi-structured JSON, this is a significant advantage.
High Cardinality Without Penalty
Unlike Prometheus, which allocates memory per unique series, ClickHouse stores high-cardinality data as regular column values. There is no per-identity overhead at ingest time. This means labels like user IDs, request IDs, or container names do not degrade performance. For a detailed breakdown, see our ClickStack vs Prometheus comparison.
Who Is ClickStack For
ClickStack is not for everyone. Here is where it makes sense and where it does not.
Good Fit
Teams moving off Datadog or Splunk If you are paying $250K+ per year for SaaS observability and want to own your data, ClickStack provides comparable features (logs, traces, metrics, session replay) at infrastructure cost only. ClickStack’s managed service pricing is less than $0.03 per GB/month for active data and $0.002 per GB/month for long-term retention — with no per-host fees, no sampling limits, and no retention trade-offs.
Teams that know SQL If your engineers are comfortable with SQL, ClickStack removes the need to learn PromQL, LogQL, and TraceQL. One language for all observability data.
High-cardinality environments If you are running large Kubernetes clusters where pod names, container IDs, and request-scoped labels create millions of unique series, ClickStack handles this natively where Prometheus struggles with memory overhead.
Organisations starting fresh If you do not have an existing observability stack and are choosing a platform for a new deployment, ClickStack provides full-stack observability from day one with fewer components to manage.
Teams that want session replay Most open-source observability platforms do not include session replay. If connecting frontend user behaviour to backend performance matters to your debugging workflow, ClickStack is one of the few open-source options that offers it.
Not a Good Fit
Teams heavily invested in Grafana If your organisation has hundreds of Grafana dashboards, Alertmanager routing trees, and years of PromQL knowledge, switching to ClickStack has a real cost. Consider running both in parallel first.
Metrics-only use cases If you only need metrics monitoring and alerting, Prometheus is purpose-built for that and more mature. ClickStack’s value is in unification across all signal types.
Teams needing enterprise alerting ClickStack’s alerting is functional but younger than Alertmanager. If complex alert routing, inhibition rules, and silencing policies are critical, evaluate carefully.
Very small teams without Kubernetes If you are running a handful of VMs and do not need distributed tracing or session replay, simpler solutions like Prometheus + Grafana or a lightweight SaaS tool may be more appropriate.
How ClickStack Compares
vs Datadog
Datadog is the benchmark ClickStack is measured against. Both offer logs, traces, metrics, and session replay in a unified platform.
| Aspect | ClickStack | Datadog |
|---|---|---|
| Deployment | Self-hosted or managed (beta) | SaaS only |
| Pricing | Infrastructure cost (or <$0.03/GB managed) | Per-host + per-GB ingestion |
| Data ownership | You own everything | Datadog stores your data |
| Integrations | OTel SDKs + Prometheus scraping | 700+ built-in integrations |
| Setup time | 15 minutes (Docker) | 5 minutes (SaaS agent) |
| Session replay | Included | Paid add-on |
| Maturity | New (2025) | Established (2010) |
| License | MIT + Apache 2.0 | Proprietary |
ClickStack wins on cost and data ownership. Datadog wins on polish, integrations, and ecosystem maturity.
vs Grafana Stack (Prometheus + Loki + Tempo)
The Grafana stack is the most popular open-source alternative and the closest architectural competitor.
| Aspect | ClickStack | Grafana Stack |
|---|---|---|
| Backend | Single (ClickHouse) | Multiple (Prometheus, Loki, Tempo, Mimir) |
| Query language | SQL + Lucene | PromQL, LogQL, TraceQL |
| Systems to manage | 2–3 | 5–6 |
| Signal correlation | SQL joins | UI-level linking |
| Session replay | Built-in | Not available |
| Dashboard community | Small | Massive (Grafana ecosystem) |
| Alerting maturity | Basic | Advanced (Alertmanager) |
ClickStack wins on operational simplicity and cross-signal correlation. The Grafana stack wins on ecosystem breadth and alerting maturity.
For a deep-dive comparison focused on metrics, see our ClickStack vs Prometheus analysis.
vs SigNoz
SigNoz is the most architecturally similar alternative — also built on ClickHouse with OpenTelemetry and offering unified logs, metrics, and traces.
| Aspect | ClickStack | SigNoz |
|---|---|---|
| Founded | 2025 (ClickHouse + HyperDX merger) | 2021 |
| Backing | ClickHouse (parent company) | Independent (VC-funded) |
| Session replay | Built-in | Not built-in |
| UI maturity | Newer | More established |
| Managed option | Beta | Available (SigNoz Cloud) |
| License | MIT + Apache 2.0 | Apache 2.0 (mostly) |
ClickStack has the advantage of being maintained by the ClickHouse team, which means tighter database integration and optimisation over time. SigNoz has a multi-year head start on UI polish and community building.
Both are covered in our all-in-one observability platform comparison.
Getting Started
ClickStack offers multiple deployment paths depending on your needs.
Local Testing (Docker)
One command to get a fully functional instance:
docker run -p 8080:8080 -p 4317:4317 -p 4318:4318 \
docker.hyperdx.io/hyperdx/hyperdx-all-in-oneOpen http://localhost:8080 and start sending telemetry to port 4318 (HTTP) or 4317 (gRPC) using any OpenTelemetry SDK.
Production (Helm)
helm repo add clickstack https://clickhouse.github.io/ClickStack-helm-charts
helm repo update
helm install my-clickstack clickstack/clickstack \
--namespace observability --create-namespaceManaged (ClickHouse Cloud)
ClickHouse is beta-testing a fully managed ClickStack offering through ClickHouse Cloud. Pricing starts at less than $0.03/GB/month with unlimited queries and no sampling.
For complete setup instructions covering Docker, Helm, and production Kubernetes with external ClickHouse, see our ClickStack setup guide.
What Is on the Roadmap
Based on ClickHouse’s 2026 announcements, the ClickStack roadmap includes:
- Fully managed ClickStack experience — GA release of the managed service on ClickHouse Cloud
- AI-powered notebooks — Interactive investigation tools with AI assistance
- Anomaly detection — Automatic identification of unusual patterns across signals
- Out-of-the-box integrations — Pre-built dashboards and collectors for common technologies
- Opinionated defaults — Sensible retention, alerting, and schema configurations that work without tuning
- LLM observability — ClickHouse recently acquired Langfuse for LLM tracing, which will likely integrate with ClickStack
The managed service and AI features signal ClickHouse’s intent to make ClickStack competitive with Datadog not just on features and price, but also on ease of use.
Frequently Asked Questions
Is ClickStack free?
Yes. ClickStack is fully open-source under MIT and Apache 2.0 licenses. You pay only for infrastructure (compute and storage). ClickHouse also offers a managed beta version with usage-based pricing starting at less than $0.03/GB/month.
Does ClickStack require Kubernetes?
No. The Docker all-in-one container runs anywhere Docker is available. However, for production deployments, Kubernetes with the Helm chart is the recommended approach for scaling and reliability.
Can I use ClickStack with my existing ClickHouse instance?
Yes. ClickStack works out of the box with any ClickHouse instance. You can deploy HyperDX and the OTel Collector separately and point them at your existing cluster. This is useful if you already use ClickHouse for analytics and want to add observability without running a second database.
How much data can ClickStack handle?
This depends on your ClickHouse cluster size. Production users of ClickHouse process over a billion events per second. For most organisations, a modest cluster (16 GB RAM, 8 cores) handles 10–100 GB/day of telemetry comfortably. ClickHouse scales horizontally by adding shards and replicas.
Does ClickStack replace Prometheus?
It can, but it does not have to. ClickStack’s OTel Collector can scrape Prometheus endpoints, so you can run both in parallel. Some teams keep Prometheus for bounded alerting metrics and use ClickStack for high-cardinality investigation data. See our ClickStack vs Prometheus comparison for a detailed breakdown.
What languages are supported for instrumentation?
ClickStack uses OpenTelemetry SDKs, which support Python, Node.js, Java, Go, .NET, Ruby, PHP, Rust, and Elixir. Any OTLP-compatible agent or SDK can send data to ClickStack.
Get Expert Help With ClickStack and Observability
ClickStack is straightforward to deploy but designing an observability strategy that scales — choosing the right retention policies, structuring alerts, managing costs, and onboarding your team — takes experience.
Our team provides observability and monitoring consulting to help you:
- Evaluate ClickStack against your current stack with a proof-of-concept tailored to your workload
- Deploy production-grade ClickStack on Kubernetes with HA ClickHouse, S3 tiered storage, and proper security
- Migrate from Datadog, Splunk, or the Grafana stack without losing dashboards, alerts, or historical data
We have deployed observability platforms across production Kubernetes clusters handling billions of events.