Datadog vs. SigNoz: OpenTelemetry, operations, and migration costs

A rising Datadog bill often sends a team looking at SigNoz. The first question is usually how much an open-source alternative could save. The more consequential question is whether the investigation that resolved the last incident will still work after the move.

SigNoz is a strong fit when the main requirements are application traces, metrics, and logs, the team already uses OpenTelemetry, and it can manage collection and data conventions. Existing Datadog investigations may also depend on user experience, synthetic testing, and security products. Those workflows, rather than the telemetry endpoint alone, determine the replacement scope. SigNoz has a managed service, and Datadog supports OpenTelemetry. Deployment control and instrumentation portability are separate choices.

Guance Editorial Team · Reviewed October 21, 2026. This documentation-based comparison covers Datadog SaaS, SigNoz Cloud Teams, and self-hosted Community, with enterprise options identified separately. We did not run a performance or cost benchmark.

Choose an operating model before comparing the bill

Datadog's SaaS backend puts platform operations with the vendor while the customer configures collection. SigNoz offers several arrangements: vendor-operated Cloud, customer-operated Community, and separate enterprise BYOC and self-hosted options. Self-hosting gives the team control over deployment and storage, together with capacity, backups, upgrades, and availability work. These are different jobs even when the same application sends the same telemetry.

Datadog collects through its Agent and SDKs as well as OTel paths; SigNoz uses Collector-based collection with OTLP and other supported sources. Both can relate traces, logs, and metrics, but the identifiers and fields still have to arrive. Datadog's other products add further workflows when enabled. A shared input protocol does not carry those workflows, existing queries, alerts, or integrations into a new platform.

The bill follows the chosen arrangement. Datadog has product-specific meters such as hosts, GB, events, and sessions. SigNoz Cloud meters log and trace GB and metric samples; self-hosting adds infrastructure and labor instead of reproducing that managed-service bill. The SigNoz edition matrix, enterprise operating models, and Datadog OTel compatibility matrix define the relevant boundaries. A listed capability does not belong to every plan.

What OpenTelemetry makes easier—and what it leaves behind

SigNoz's collection architecture uses OpenTelemetry, with telemetry flowing through a Collector into ClickHouse. OTLP is not its only possible input: the architecture documentation also lists Jaeger, Zipkin, and Kafka, among others. Actual support depends on the receivers and configuration deployed. ClickHouse is the telemetry store; a unified backend does not mean a production installation consists of one database process. SigNoz architecture

Datadog accepts OpenTelemetry data too. DDOT, upstream Collector, and direct OTLP paths differ in supported features. Check the matrix against your language, signals, and products before choosing Datadog SDKs, OTel, or a staged combination. Seeing traces arrive does not establish parity for profiling, application security, or service metrics.

OTel can reduce the degree to which application instrumentation and export are tied to one backend. It does not automatically migrate dashboard queries, alert rules, authorization, historical data, or on-call habits. Less reinstrumentation is a reasonable expectation. A cost-free switch with no vendor dependencies is not.

A retry explains more than a service name

An order endpoint occasionally times out. The database query is quick, but a downstream call retries repeatedly. The useful evidence is in those retry spans and the logs they connect to. Service, environment, and version narrow the request population; the individual trace reveals whether latency comes from one slow attempt or several repeated attempts. Seeing the service listed in both products establishes much less than preserving that explanation.

SigNoz correlates logs using trace_id and span_id. Supported OTel logging integrations can attach those identifiers within an active span; file-based or Kubernetes logs may still need parsing and field mapping. A request ID printed somewhere in a message is not automatically a recognized trace field. Trace/log correlation and field parsing

Datadog needs correct log/trace correlation as well. Check service and environment tags, trace identifiers, and sampling. Different request counts can reflect sampling or aggregation rather than missing ingestion. Latency percentiles are only comparable when the time windows, request populations, and filters agree. Datadog correlation

Guance's trace details follow that same request into collected logs and related host or container data. If the retry coincides with resource pressure, keeping this context together can save a separate search; if the relevant telemetry was never collected, a shared interface cannot fill the gap. This makes correlation fields and collection scope part of the platform decision alongside the choice of backend. Guance trace details.

Self-hosting changes responsibility, not just the recipient of the bill

SigNoz Community can be self-hosted. The main repository's license distinguishes ordinary code from enterprise code under ee/, while third-party components retain their own licenses. Do not describe every part of the product as covered by one open-source license. Repository license

Operating it means planning for ingestion peaks, concurrent queries, disks and retention, database backups, upgrades, and recovery. A successful single-machine installation proves the collection path works; it does not establish production capacity. Test your log volume, span sizes, metric cardinality, and query load rather than assuming a vaguely defined medium-sized workload fits one machine. Self-hosted installation

SigNoz Cloud is an option for teams that do not want to run the backend. Enterprise BYOC puts a vendor-managed deployment in the customer's cloud account; enterprise self-hosted deployments are customer-operated with the contracted support. Those responsibilities are different.

Check authentication, roles, and audit requirements individually. “All SSO requires enterprise” is too broad to substitute for checking the actual identity method and edition. Features marked as coming soon on a pricing page should not be treated as available today.

Calculate with your data

At the review date, SigNoz Cloud Teams starts at $49 per month, including $49 of usage. The default pricing display lists logs and traces at $0.30 per ingested GB with 15-day retention, and metrics at $0.10 per million samples with one-month retention. Longer retention changes the calculation. Enterprise and self-hosted deployments do not use this same managed-service bill. SigNoz pricing

No host-based charge does not mean cardinality is free. Each active time series emits samples at its export interval. With 10,000 series reporting every 30 seconds over 30 days, the total is 864 million samples: $86.40 of monthly metric usage at that rate, before logs and traces. This is not a full $86.40 added on top of the $49 included usage. Calculate aggregate usage, then apply the minimum and allowance correctly. Metric billing

Datadog estimates should include the products actually required. Host-based APM starts at $31 per host per month on annual billing when paired with Infrastructure Monitoring; standalone APM starts at $36 per host per month. Logs, RUM, other modules, and usage beyond included allowances may add charges. Comparing one SigNoz ingestion line with a complete Datadog bill is not a like-for-like estimate. Datadog pricing

Self-hosted estimates need compute, disks, backups, networking, and operations. Reducing noisy telemetry, controlling cardinality, and setting appropriate sampling and retention are useful before changing platforms. This article has not measured savings and does not adopt a vendor's advertised savings percentage.

Dual delivery preserves continuity, at a cost

During dual delivery, the existing path keeps historical queries and alerts available while the new backend starts building its own history. Metric units and aggregation, resource attributes, log timestamps, and trace continuity must retain their meaning for those two views to be comparable. Meanwhile, the Collector has another destination to queue, retry, and transmit to. Keeping the overlap bounded avoids turning a temporary migration cost into a permanent operating arrangement.

Browser replay, synthetic tests, security detection, profiling, and third-party integrations often remain tied to the old platform after basic telemetry has moved. SigNoz currently documents frontend Web Vitals and mobile monitoring, so calling it a product with no RUM is inaccurate. Those capabilities do not establish parity with every Datadog replay, synthetic, or security product. A tool that still performs useful work can remain without preventing a narrower telemetry migration.

Historical queries, permissions, and alert routing also survive as separate obligations. Redirecting new telemetry does not give the new backend older records, nor does it transfer who may read them or who receives an alert. A partial migration can therefore be the finished architecture when it preserves those useful paths with less work than replacing them.

Which option fits?

Choose SigNoz Cloud when logs, metrics, and traces are the core requirement, OTel is already in place, usage-based budgeting is attractive, and the team does not want backend operations work.

Choose self-hosted SigNoz when deployment and storage control are concrete requirements and the team can own capacity, backups, upgrades, and availability. Confirm Community and paid-feature boundaries first.

Keep or choose Datadog when existing cross-product investigations, integrations, and organizational workflows have demonstrated value, and the team wants a vendor-operated backend while managing module and data spend. SaaS removes backend operations, not collection, permission, or billing work.

The strongest reason to move is a recurring constraint the new operating model resolves: control over storage, a better fit between usage and spend, or a simpler logs-and-traces workflow. Where Datadog's other products are doing useful work, keeping them during a partial migration can cost less than rebuilding those investigations elsewhere.

Official references

• SigNoz architecture, installation, and license
• SigNoz editions and pricing, metric-sample billing, and enterprise responsibilities
• Datadog OTel compatibility, log correlation, and pricing

Sources checked October 21, 2026. Prices use public USD terms; recheck Region, taxes, contracts, and product editions before purchasing.