New Relic vs Dash0: What Survives an OpenTelemetry Migration?

Changing an OpenTelemetry Collector's destination can take a few lines of configuration. Letting an on-call engineer find the same failed request in the new platform can take much longer. Service names, sampling, log correlation, alerts and historical data do not align automatically because both vendors accept OTLP.

That migration is a useful way to compare New Relic and Dash0. New Relic offers both its own application agents and native OpenTelemetry ingestion. Dash0 organizes collection and investigation around OpenTelemetry, PromQL and Perses. The practical question is how much of today's operational work survives—and what needs validating again.

Start with what was actually collected

Suppose checkout moves from synchronous HTTP to a message queue. Browser response time still looks healthy, but orders arrive late. Consumer spans, propagated message context and trace identifiers in logs matter more than the number of panels on the homepage.

New Relic's native OTLP endpoint accepts OpenTelemetry data and is the recommended ingestion route, with HTTP/protobuf preferred. Region, authentication and signal paths need to match. Signal-specific endpoint settings handle paths differently from the generic setting. New Relic is not restricted to data from its own agents.

The Dash0 Kubernetes Operator installs a Collector and arranges automatic instrumentation for supported runtimes. Its current list includes Java, Node.js and .NET, with Python and Ruby opt-in. Log and metric collection are independent of that runtime list. Other applications still need suitable SDKs or collection methods.

Automation also has deployment consequences. The configuration documentation says enabling monitoring for a namespace restarts its workloads by default to apply instrumentation. Start with a representative synchronous and asynchronous path rather than every production namespace.

An open format moves only part of the system

Dash0's dashboards use Perses and can bring logs, metrics, traces, resources and web events into one canvas. A standard dashboard format helps manage configuration and move it between compatible systems. The destination still needs matching data sources, fields and query semantics.

Existing NRQL queries, business alerts and New Relic application entities do not automatically become PromQL or Perses. Nor does OpenTelemetry supply attributes the application never generated. Customer tier, order stage and retry count still need deliberate instrumentation or processing.

An established investigation contains implicit configuration: how a service is identified, which logs belong to a failed consumer operation, and which time range an alert link opens. Losing one step after migration can reflect attributes, sampling, or access rather than a query-engine limitation. Open standards make data easier to send elsewhere; those investigative conventions still have to move with it.

Guance's OpenTelemetry integration guide provides another standard ingestion path. Resource attributes and trace identifiers let existing business requests remain useful for investigation, within the supported integration scope and the context actually recorded. Open collection adds backend choices; preserving the meaning of an investigation is separate work.

Matching metric names can hide different aggregation

Successful ingestion does not make two charts directly comparable. New Relic recommends delta temporality where appropriate for its OTLP metrics architecture. Cumulative data is supported, but the choice can affect SDK memory and ingest volume. Instrument-specific rules matter: gauges and up-down counters should not blindly inherit counter settings. Read the metrics guidance alongside the endpoint recommendations.

Hold collection interval, labels and aggregation windows constant before comparing request rates or latency distributions. A cumulative value beside a rate is not evidence of missing data. Histogram boundaries, resets and duplicate collection also change results.

For checkout, retain an external business reference such as confirmed order counts. It does not replace telemetry, but it helps expose a reassuring chart produced by sampling or an incorrect aggregation.

Profiling requires distinguishing transport from collection

Saying Dash0 has no profiling is outdated. Assuming the Operator automatically collects every profile is also incorrect. The current profiling guide documents accepting, processing and exporting OTLP profiles after enabling the feature. Collection still requires a separate profiler, such as the OpenTelemetry eBPF profiler.

Profiles also bypass namespace-specific exports and use the Operator's default export. That matters when namespaces have different data-routing requirements. Validate runtime support, kernel privileges and destinations rather than treating an acquisition announcement as proof of deployment readiness.

CPU profiles and slow requests describe different evidence on either platform. A request waiting for an external payment API can be slow without consuming much local CPU. A useful trial makes request timelines and profiles explain one another rather than asking a flame graph to answer every latency question.

Counts and gigabytes are different billing inputs

Dash0's published base rates separate ingestion from storage. Per million logs, spans or web events, the listed charges are $0.06 and $0.54 with 30-day retention. Metric points are $0.02 and $0.18 with 13-month retention. Check tiers and contract terms separately. Signals filtered by SignalControl still incur ingestion, while their storage charge is avoided. Agent0 credits and per-seat AI SDLC Insights are additional meters, so a blanket claim of no seats or add-ons would be misleading.

New Relic's pricing documentation describes Data + User and Data + Core Compute. Core Compute remains marked Preview and requires discussing access with the account team; it changes the assumption that every evaluation must revolve around paid seats. Advanced Compute is another capability and usage layer. Under the user model, Basic users can query and use custom dashboards without gaining all curated APM interfaces.

Measure both record counts and processed gigabytes. Many short messages and fewer large stack traces can occupy similar bytes but produce different count-based bills. Extra attributes can change byte-based usage. Combine representative samples with retention, query activity and team access before comparing totals.

Dash0's budget controls include warnings and a grace period before ingestion pauses. A spending cap is therefore also a continuity decision: establish who can adjust it and how the on-call team learns that collection stopped.

Choose for the next investigation

If the team depends on New Relic's application workflows and accumulated rules, first test whether native OTLP meets the goal of open collection. If OpenTelemetry, PromQL and configuration as code already shape the team's work, Dash0 deserves a trial covering runtime support, permissions, profile routing and billing.

Migration does not end when dual export stops. Old incident links, historical baselines and alert ownership need a destination too. Success means the next engineer can continue an investigation, not merely that a demo shows incoming data.

Documentation checked October 21, 2026. No performance, reliability or total-cost benchmark was performed.