What HyperDX means in the ClickStack era
HyperDX remains the correct product name for the user interface, but it is no longer accurate to describe it as an entirely separate observability platform with its own current cloud offer. ClickHouse documentation defines ClickStack as three coordinated components: the ClickStack UI, identified in parentheses as HyperDX; a preconfigured OpenTelemetry Collector; and ClickHouse as the analytical database. The standalone hyperdxio/hyperdx repository uses the same boundary, calling HyperDX a core ClickStack component that searches and visualizes logs and traces on any ClickHouse cluster. This review therefore evaluates HyperDX as the interface and application layer, while using ClickStack for the full collector, storage, and UI product and Managed ClickStack for the ClickHouse Cloud service.
That boundary drives the verdict. HyperDX is a strong choice for engineering teams that already prefer ClickHouse, want OpenTelemetry-centered collection, and value a single investigation surface for logs, traces, metrics, and browser sessions. It is less convincing as a drop-in purchase for a team that wants an infrastructure-neutral hosted service with a simple per-user plan, because the central architectural commitment is ClickHouse and the managed commercial path is sold through ClickHouse Cloud. The product's appeal is not merely an attractive dashboard: it is the combination of a ClickHouse-aware query layer, cross-correlated telemetry, and deployment freedom. Buyers should judge the whole operating model, not compare the UI alone with a turnkey SaaS console.
Search, correlation, and incident investigation
The public feature set covers the essential investigation loop without forcing every user into SQL. HyperDX supports Lucene-style full-text and property filters, optional native SQL, live tail for logs and traces, interactive dashboards, alerts, trace exploration, APM views, native JSON-string queries, event deltas, and log-pattern recognition. ClickStack stores logs, traces, metrics, and session data in separate ClickHouse tables while keeping them queryable and cross-correlatable at the database layer. That design is especially relevant during incident triage: an engineer can move from a front-end session to a trace and its related logs in one interface, rather than matching timestamps manually across separate products. The official docs also describe schema-agnostic sources, so the UI is not limited to the default OpenTelemetry table layout.
Session replay is a meaningful differentiator, but it is an instrumented capability rather than magic built into the database. ClickHouse's May 2026 update says teams collect replays, Core Web Vitals, JavaScript errors, API failures, and user interactions through the HyperDX Browser SDK or another OpenTelemetry browser agent; the release added a Browser RUM dashboard template with p75 LCP, INP, and CLS views. For back-end analysis, the current ClickStack surface includes service maps, event patterns, alerting, and SQL-based visualizations, while the HyperDX repository documents high-cardinality dashboards and event deltas. These are credible reasons to shortlist the product for root-cause work, but the evidence is feature documentation, not an independent latency benchmark, so this review does not repeat vendor claims about sub-second searches or cost savings as measured results.
Deployment choices and operational burden
ClickStack offers six materially different deployment paths, and choosing the wrong one changes the risk profile. Managed ClickStack hosts ClickHouse and the HyperDX UI in ClickHouse Cloud; the all-in-one image bundles every core component but is explicitly limited to demos, proofs of concept, and other non-production use; Docker Compose can serve local testing or a single production server but has no fault tolerance; the official Helm chart is the recommended production route on Kubernetes; HyperDX-only attaches the UI to an existing ClickHouse environment; and local browser mode has no authentication, persistence, or alerting. This range is excellent for evaluation and migration, yet it means a buyer cannot treat a successful all-in-one demo as evidence that production operations will be equally simple.
The production Helm path makes the hidden dependencies concrete. The current v2 chart uses a two-phase installation: operators and CRDs are installed first, then the main chart creates operator-managed resources for ClickHouse, MongoDB, and the OpenTelemetry Collector alongside the HyperDX UI and API. In HyperDX-only mode, ClickHouse is not included, ingestion is entirely the user's responsibility, and MongoDB is required for full application state such as dashboards, saved searches, user settings, and alerts. Teams can feed ClickHouse through their own OpenTelemetry Collector, client libraries, Kafka or S3 table engines, ETL pipelines, or ClickPipes, but that flexibility transfers schema, retention, backup, security, and pipeline ownership to the operator. Existing ClickHouse expertise turns this into leverage; without it, the same architecture becomes the primary adoption cost.
Open-source control and extensibility
The licensing story is unusually clear at the component level. HyperDX itself is MIT licensed, while the ClickStack parent documentation lists ClickHouse and the OpenTelemetry Collector under Apache 2.0. The HyperDX repository remains public and active, and the ClickStack parent repository is best understood as a stack-level distribution containing deployment artifacts rather than the sole implementation repository. This split matters when evaluating community health or maintenance: HyperDX UI issues and releases belong to hyperdxio/hyperdx, database work belongs to ClickHouse/ClickHouse, and stack-wide Docker Compose material belongs to ClickHouse/ClickStack. Calling the small parent repository the entire product would understate the actual codebase; calling every managed ClickHouse Cloud capability open source would overstate the license boundary.
Open code also provides genuine data-control options. HyperDX-only can connect to an existing ClickHouse cluster and any event schema, not just the opinionated OpenTelemetry schema, while the full stack can ingest through the recommended ClickStack collector or custom native pipelines. SQL access avoids a proprietary query language dead end, and ClickHouse tables remain available to other analytical tools. The trade-off is that portability does not eliminate architecture: dashboards, alerts, source definitions, and user settings still depend on the HyperDX application layer and MongoDB in self-managed full-function deployments. Buyers in regulated environments should value the ability to place storage and services inside their own boundary, then separately budget for access control, upgrades, backups, retention policies, and the operational evidence their compliance program requires.
Pricing and total cost of ownership
There is no current standalone HyperDX SaaS price that should be copied into this review. Self-hosting the MIT-licensed UI and open-source ClickStack components removes a software-license fee, but it does not remove ClickHouse compute and storage, MongoDB, collector capacity, Kubernetes or VM resources, backups, and engineering time. For a managed reference point, ClickHouse's AWS us-east-1 pricing page at verification time displayed Basic compute at $0.2181 per unit-hour and storage at $25.30 per TB-month, while Scale compute was $0.2985 per unit-hour with the same displayed storage rate. Those are regional ClickHouse Cloud dimensions, not a guaranteed all-inclusive HyperDX rate, and an actual estimate must include workload shape, availability, retention, support, and data movement.
Managed ClickStack currently advertises a 30-day trial with $300 in credits and uses ClickHouse Cloud's separated storage-and-compute model. The purchasing caveat is availability as well as arithmetic: the Managed ClickStack landing page presents an active trial and beta framing, while a separate ClickHouse Cloud HyperDX documentation page still labels the feature private preview and organization-level enablement. Procurement should therefore confirm region, account eligibility, support level, and contract pricing directly rather than relying on an obsolete standalone HyperDX price table or a third-party per-metric quote. HyperDX can be cost-efficient when an organization already operates ClickHouse or values long retention, but the honest comparison is total platform cost, including on-call ownership, not zero-dollar license versus a hosted invoice.
Who should choose HyperDX, and who should keep looking
Choose HyperDX when ClickHouse is already strategic, OpenTelemetry is the collection standard, and incident responders need logs, traces, metrics, alerts, and browser sessions to meet in one investigation surface. It is particularly well aligned with high-cardinality event data, custom schemas, teams that want both Lucene-style search and unrestricted SQL, and organizations that need a self-managed path without surrendering raw telemetry to a closed storage backend. Existing ClickHouse users can deploy only the HyperDX UI over populated tables, while Kubernetes teams can adopt the supported Helm chart and scale collectors, storage, and UI components separately. That combination of reusable data, open interfaces, and deployment choice is the clearest reason to buy into the ecosystem.
Keep looking if the requirement is a turnkey hosted product with mature availability in every account, a flat and easily forecast per-seat or per-host price, or a backend that can be swapped without changing the product's core value proposition. Also pause if the team cannot own ClickHouse capacity planning, MongoDB state, collector configuration, retention, and upgrades, because the self-hosted edition turns those into internal responsibilities; the all-in-one container is not the production escape hatch. The final recommendation is positive but specific: HyperDX is one of the most compelling open-source observability interfaces for ClickHouse-centered teams, while Managed ClickStack still requires a write-time availability and pricing check. It should be selected for architectural fit and investigation workflow, not on unsupported claims that it is universally cheaper or operationally effortless.