urgentry vs HyperDX: errors-first vs ClickHouse-backed observability

What HyperDX is in 2026

HyperDX started as a Y Combinator W22 company building a developer-first observability UI on top of ClickHouse. It went open source under Apache 2.0 in 2023, picked up traction in the OpenTelemetry community, and was acquired by ClickHouse Inc. in March 2025.

After the acquisition, HyperDX v2 was rebuilt as the rendering layer for ClickStack. ClickStack is the name ClickHouse gave to its official observability bundle: a ClickHouse cluster, an OpenTelemetry collector pre-configured for ClickHouse export, and HyperDX as the UI. The pitch is one column-store for logs, traces, metrics, and session replay, with one UI that searches across them.

The product covers four signals end to end. Logs and traces arrive over OTLP from any OpenTelemetry SDK and land in ClickHouse via the collector's ClickHouse exporter. Errors are not a separate signal in HyperDX's model. They are exceptions on spans, captured through the OpenTelemetry exception semantic conventions, and surfaced in a dedicated error-search view. Session replay is rrweb-based and links session events back to the same traces.

That is the important architectural choice: HyperDX does not have a separate error pipeline. Everything is a span attribute query against ClickHouse, including the error view.

What urgentry is

urgentry is a single Go binary that implements the Sentry ingest envelope and 218 of the 218 documented Sentry REST API operations. It runs against SQLite by default and Postgres optionally. The license is FSL-1.1-Apache-2.0, which converts to Apache 2.0 after two years.

The product surface stops at errors plus OTLP intake. Errors live in their own pipeline because they have their own data shape: fingerprint, grouping, frequency rollup, release-health windows, alert rules tied to issue state. OTLP spans and logs land in the same backend through an OTLP endpoint, but the binary is designed around the issue list, not the trace explorer.

The deployment shape is one process. There is no separate collector, no separate database for the small-scale path, no message broker, no UI service. ./urgentry serve binds the port and starts accepting events. The compatibility matrix at /sentry-alternative/ documents which API operations are covered today.

The SDK story is the headline difference

HyperDX speaks OpenTelemetry. urgentry speaks the Sentry envelope. That choice cascades through everything else in the comparison.

For a service already instrumented with sentry-sdk, @sentry/node, sentry-go, or any other Sentry SDK, urgentry is a DSN change. The library code does not move, the integrations do not move, the breadcrumb policy does not move. You set SENTRY_DSN to your urgentry host and restart. Events arrive.

For the same service to send to HyperDX, you remove the Sentry SDK and instrument with OpenTelemetry. That is the right answer for greenfield services, where OTel is increasingly the default anyway. It is meaningful work for the long tail of Rails apps, Django apps, and Next.js services that already ship Sentry events to production.

A worked example. A Django service has sentry-sdk[django] in requirements.txt and sentry_sdk.init(...) in settings.py. To move to urgentry, the diff is one line:

sentry_sdk.init(
    dsn=os.environ["SENTRY_DSN"],  # value changes; code does not
    integrations=[DjangoIntegration()],
)

To move the same service to HyperDX, the diff is the SDK itself: install opentelemetry-distro and opentelemetry-instrumentation-django, configure the OTLP exporter, and rewire any capture_exception call sites to record_exception on the active span. That is a real migration. It might be the right one, but it is the choice the SDK story forces.

The middle path is to run an OpenTelemetry collector that translates Sentry envelopes to OTLP. Such collectors exist, including community contrib packages, but they are an extra hop and they lose Sentry-specific fields like release health sessions in translation. The honest framing is: if you have Sentry SDKs in your repos, urgentry's DSN swap is a real path. HyperDX is a re-instrumentation.

Storage and the operational footprint

The storage choice is the second pivot. urgentry writes events to SQLite or Postgres in the same process that ingests them. HyperDX writes everything to ClickHouse through a collector.

ClickHouse is a column store optimized for analytical queries over billions of rows. It is fast in ways relational databases are not. It is also a real piece of infrastructure. The HyperDX local dev image bundles ClickHouse, the OTel collector, and HyperDX into one container for evaluation. The production guidance is a real ClickHouse deployment with separate keeper nodes for the cluster coordination layer, with replication for durability, and with enough RAM for the merge tree to be healthy. A common starting size is two ClickHouse nodes at 16 GB RAM each plus three keeper nodes at 2 GB each. ClickStack lowers the friction by providing pre-built Helm and Compose recipes, but the underlying cluster is what you are running.

urgentry's storage footprint is the events database and the source-map blob store. SQLite for the first one runs in-process. Postgres for the second one runs anywhere you can run a Postgres. The benchmark page documents 400 events per second on a $5 VPS against SQLite, which is enough for many real production teams.

The trade is concrete. ClickHouse will outperform SQLite by orders of magnitude on a thousand-million-row trace search. SQLite will be cheaper, simpler, and adequate for an error volume of one to twenty million events per month, which is where most teams actually live. If your daily span volume is in the hundreds of millions, ClickHouse is the right answer and the cluster cost is the price of admission. If your error volume is in the millions and you do not have a separate need for trace search at scale, that cluster is overhead you do not have to pay.

The 2025 community signal supports this split. The Fireship video on the LGTM stack pulled close to 800,000 views, which says a lot about how much interest there is in the bigger observability stacks. The r/selfhosted discussion threads from the last 30 days keep returning to the same theme: people want fewer moving pieces unless the data volume forces more of them.

Coverage matrix

A direct read on what each project ships today:

                          HyperDX (ClickStack v2)      urgentry
Errors                    OTel exceptions on spans     Sentry envelope ingest
Traces                    OTLP-native, ClickHouse      OTLP intake, simple search
Logs                      OTLP-native, ClickHouse      OTLP intake, attached to issues
Metrics                   OTLP-native, ClickHouse      Not in scope
Session replay            rrweb, in product            Not in scope (P2 roadmap)
Profiling                 Via OTel profiling SIG       Not in scope (pair w/ Pyroscope)
Source maps               Via OTel debug-symbols       Sentry-CLI compatible
Alert rules               Search-based, on ClickHouse  Issue-state-based, native
Storage backend           ClickHouse cluster           SQLite or Postgres
Ingest protocol           OTLP                         Sentry envelope + OTLP
SDK story                 Re-instrument to OTel        DSN change on Sentry SDK
License                   Apache 2.0                   FSL-1.1-Apache-2.0
Cloud option              ClickHouse Cloud             None today

A short read of the matrix: HyperDX covers more signals, urgentry covers errors better. That is not a value judgement. Errors better means the issue model is a native object with grouping, frequency, regression detection, and alert rules tied to issue transitions. In HyperDX, "errors" are a saved search across spans with otel.status_code = ERROR or an exception event attached. That search runs fast against ClickHouse, but it is a search, not an issue.

Where each one fits

Three concrete scenarios, with the honest call on which one fits.

You are running Sentry SaaS today and the bill is the trigger. urgentry is the shorter path. The SDK code does not move, the DSN does. You stand up a binary, change one environment variable, watch the events arrive, and the migration is done in an afternoon. HyperDX in this scenario asks for a re-instrumentation across every service, which can be the right project but is not an afternoon.

You are greenfield and the team has already committed to OpenTelemetry. HyperDX is the natural fit. The instrumentation is already where HyperDX wants it. The cluster cost is real, but you are also getting traces, logs, metrics, and session replay in one product instead of stitching them together. urgentry in this scenario is a partial picture: it covers errors well, but it does not give you the trace explorer you would expect from a full observability platform.

You want both, on a budget. Run urgentry for errors and ClickStack only if you actually have the data volume to justify ClickHouse. Most teams do not. The OTel collector can fan errors out to urgentry as Sentry envelopes and traces out to ClickStack at the same time, so the SDK does not have to choose. The deployment shape is two backends behind one collector. This is the "Logs vs traces vs errors" division we wrote about earlier, made concrete.

The shared stack pattern

For teams that genuinely want both products, the OpenTelemetry collector is the integration point. A minimal collector config:

receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }

processors:
  batch: { timeout: 5s }

exporters:
  clickhouse:
    endpoint: tcp://clickhouse:9000
    database: otel
  sentry:
    dsn: ${env:URGENTRY_DSN}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [clickhouse]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [clickhouse]
    # Errors fan out to both: searchable in ClickStack, grouped in urgentry
    traces/errors:
      receivers: [otlp]
      processors: [batch, filter/errors_only]
      exporters: [sentry]

The collector contrib distribution ships a Sentry exporter that re-serializes OTel exception events into Sentry envelopes, so urgentry sees what it knows how to group, and ClickStack sees the full trace. The cost is one extra process and a collector config file. The benefit is that the issue list keeps its native shape while the trace explorer gets to live next to it.

Licensing and the long-term question

HyperDX ships under Apache 2.0. urgentry ships under FSL-1.1-Apache-2.0, which converts to Apache 2.0 after two years. Both are usable in commercial settings today. The FSL adds a non-compete window that blocks a competitor from taking the source and running it as a paid service against urgentry. For internal use, the licenses are functionally equivalent.

The acquisition matters for HyperDX governance. The project is now developed inside ClickHouse Inc., which has been clear that the OSS edition stays open. The roadmap is tied to ClickStack, which means the product direction is set by what makes ClickStack a stronger Datadog alternative. That has been good for HyperDX in 2025: the v2 release shipped faster than the OSS edition would have alone. Whether it remains good in 2027 depends on questions that are not visible yet.

The bottom line

HyperDX and urgentry are not really competing for the same job. HyperDX wants to be the unified observability stack. urgentry wants to be the error tracker that does not require a cluster. Teams that need the unified stack and have the data volume to feed ClickHouse should run HyperDX. Teams that have Sentry SDKs in their code today and want their bill to stop should run urgentry. Teams that fall in between can run both behind a collector and pay for one ClickHouse cluster instead of one Datadog contract.

The decision is rarely between these two tools alone. It is between the architecture each one assumes about the rest of your stack. Pick the architecture first; the tool follows.

Frequently asked questions