Datadog vs. Dash0: OTel workflows, filtering, and signal pricing

A platform team moves several services to OpenTelemetry. Metrics, logs, and traces are arriving successfully. At the end of the month, however, removing noise from dashboards has not reduced the bill by the same proportion. The protocol is consistent; the next questions are where filtering happens and which data is still metered.

Datadog versus Dash0 is best approached through that distinction. Keeping OTel instrumentation does not require abandoning an established Datadog investigation process. Dash0 offers another way to organize OTel data, queries, dashboards, and consumption. Open protocols can reduce application changes without making backend migration configuration-free.

Guance Editorial Team · Reviewed October 21, 2026. This guide uses current official documentation. We did not benchmark performance, assess AI accuracy, or measure actual customer bills.

Data can arrive without becoming correlated

Suppose an order trace goes to the production dataset while application logs go to a test dataset. Each record can be found separately, but the trace has no related logs. An OTel-native backend cannot resolve a separation created by the data configuration.

Dash0 uses datasets to separate telemetry within an organization. Its documentation says data that should correlate must share a dataset. The Dash0-Dataset header selects the destination, and the authentication token needs permission to write there. Without the header, ingestion uses the token's default dataset. Datasets

Service names, environments, timestamps, and trace/span identifiers then provide the necessary context. Automatic instrumentation covers supported libraries; unusual business operations or asynchronous work may need additional instrumentation. Regional endpoints, authorization, and Collector pipelines still matter. Dash0's Python guide distinguishes local-Collector and direct-export configurations, including authorization and dataset headers for direct export. Ingestion example

Datadog also supports OTel. DDOT, the upstream Collector, and direct OTLP have different feature matrices. Receiving a trace does not establish parity for service metrics, profiling, or application security. Preserve the evidence engineers actually use, not just a successful connection. Datadog compatibility

A familiar error-rate chart can calculate something different

Dash0 supports PromQL for metric analysis and Perses for dashboard definitions. Those choices help preserve queries and exportable configuration, but names, labels, and data sources still need to match. Dash0 documents its own PromQL behaviors and recommends selecting original OTel metric names with otel_metric_name where appropriate. Metric queries, dashboards

A cumulative request counter is a useful example. The visual interface may apply an increase calculation automatically, while a handwritten query needs an explicit increase() or another suitable expression. Plotting the cumulative value instead still produces a chart, but it answers a different question.

Dash0 also exposes raw logs and spans through synthetic metrics calculated on demand. These are not necessarily separately stored time series that survive removal of the underlying records. Before dropping apparently redundant logs, understand whether a team uses them to construct an investigation view. Synthetic metrics

Datadog queries, Monitors, permissions, and notification routes do not travel with an OTLP export. Perses supports compatible dashboard definitions; it does not make every Datadog dashboard directly importable. Protocols, visualization formats, and platform configuration solve different migration problems.

Filtering before ingestion is different from filtering after it

Dash0's current price page separates telemetry Ingestion from SignalStore storage. Every signal entering the service incurs ingestion consumption. Signals filtered by SignalControl avoid storage charges, but ingestion remains billable. That differs from an unqualified claim that filtering makes received data free. Current pricing

Published base rates for logs and spans are $0.060 per million for ingestion and $0.540 for storage, with 30-day retention. Metric data points are $0.020 and $0.180 per million, respectively, with 13-month retention. Volume tiers, SignalControl Edge, and contractual terms can change the applicable calculation.

For a month containing 100 million ingested logs, of which 20 million are retained, the base-rate calculation before tiers and other usage is:

100 × $0.060 + 20 × $0.540 = $16.80

Retaining all 100 million would give $60 under the same assumptions. Neither figure includes spans, metrics, web events, synthetics, or AI. Dropping records in a customer-operated Collector before sending them avoids that ingestion path, but also removes evidence and leaves the Collector's operating costs with the team.

Record counts still need a workload model

Charging per signal does not make the number of signals predictable. Ten log records per request versus a hundred, repeated output during retries, or a traffic increase can materially change consumption. Additional metric label combinations create more series and therefore more exported data points.

The same 100 GB can contain relatively few large records or many small ones. Comparing a Datadog per-GB ingestion rate with a Dash0 per-million-record rate requires that conversion. Record size still affects network, SDK, and Collector resources; a billing unit is not a promise of unlimited payloads.

Datadog's estimate must include the products actually used: infrastructure, APM, logs, RUM, and others. Logs themselves have Standard, Flex, and archive paths. Current annual-billing host APM starts at $31 per host per month when paired with Infrastructure Monitoring, or $36 for standalone APM. One of those prices does not represent the whole investigation platform. Datadog pricing

Dash0 should not be described as charging every feature solely by telemetry count either. Agent0 consumes credits, and the current code-analysis offering has per-user pricing. A historical announcement removing the telemetry base subscription fee does not establish the terms of every current product or contract.

Budget controls can affect evidence availability too. Dash0 documents warnings near a monthly limit and a grace period before ingestion is paused. This can constrain spending, but it does not guarantee complete data during an incident spike. Somebody needs to respond to budget notifications before a spending control becomes an observability gap. Cost and budget controls

A normally quiet service may emit many retry records precisely when it fails. Those records increase consumption and may also be the most valuable evidence. Decisions about detail, aggregation, and source filtering should account for incident work; a lower telemetry bill can otherwise become more engineering time spent reconstructing a failure.

Move the response process, not just the query

A rule producing the expected result is only part of an alerting workflow. Datadog has an On-Call product, so older comparisons that say it has no rotation capability are incorrect. On-Call

Dash0 can turn a query into a check rule, but the organization still needs notification destinations, escalation, and response ownership. Successfully sending one message is not evidence that the complete incident process has moved.

Browser experience, synthetic checks, profiling, security, and AI also have their own ingestion and entitlement requirements. Product age is not a reliable way to infer absence or maturity. Dash0's current pricing page includes web and synthetic functionality; an old feature list should not override current scope. Useful existing capabilities can remain on the original platform during a partial migration.

When a different investigation environment helps

Dash0 is a natural candidate for a team with established OTel conventions, substantial PromQL experience, and a willingness to manage datasets and signal consumption. The benefit comes from the fit between the data model and working habits, not a guarantee of zero lock-in.

Keeping Datadog is equally reasonable when cross-product investigations and response processes are already valuable. A bounded service can reveal changes in data, queries, and consumption before a broader cutover. That makes it easier to identify which work the new platform actually removes.

Reusing OTel with Guance

Guance provides a documented OpenTelemetry ingestion path. Reuse supported instrumentation for the telemetry needed in a shared investigation, then confirm service identity and correlation.

Standard ingestion can reduce application changes. Sampling, queries, dashboards, and notifications still need to reflect the business. Guance service costs and migration effort belong in the same calculation; a common protocol does not make all platform configuration interchangeable.