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.

Replay a known investigation as a migration test: identify the affected service, narrow it to a failed consumer operation, inspect related logs, and follow an alert link into the correct time window. When a step is missing, investigate attributes, sampling and access before blaming the query engine. Open standards reduce some migration work; they do not eliminate it.

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.

Reuse the same validation path in Guance

Guance's OpenTelemetry integration guide offers another starting point for that exercise. Use the same business request to verify supported ingestion, resource attributes and trace correlation. Open collection creates options; preserving the context needed to use those options remains an engineering responsibility.

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