What is dd-trace? And Why Teams Move to SigNoz for OpenTelemetry Tracing

TL;DR

• SigNoz: OpenTelemetry-native APM with a Datadog-style UI, a Datadog dashboard migrator, and Datadog Receiver support for staged migrations off dd-trace.
• Datadog (dd-trace): Per-host APM charges and a proprietary wire protocol that ties your tracing code to the Datadog Agent, so migrating vendors later means rewriting the entire instrumentation.

dd-trace is the tracing library Datadog ships as part of Datadog APM. It runs inside your application and records what your services are doing like incoming requests, database queries, calls to downstream services and sends that data to the Datadog Agent, which forwards it to Datadog. The result is what you see in the Datadog UI as traces, service maps, and APM metrics. Datadog ships a separate dd-trace package for each supported language (Python, Node.js, Go, Java, Ruby, .NET, and PHP), and the exact package names differ slightly across ecosystems.

dd-trace gets your tracing data into Datadog, but it does so by locking your application into Datadog's ecosystem. The libraries talk to Datadog's Agent in a proprietary protocol, they require Datadog-specific configuration such as DD_SERVICE, DD_ENV, DD_TRACE_AGENT_URL, and similar env vars. Once your code is instrumented with dd-trace, moving to any other observability backend means swapping out the SDK entirely, not just redirecting traffic to a different endpoint.

This article walks through what dd-trace actually does, how it's set up across each language, the common setup issues, and how teams replace it with OpenTelemetry and SigNoz.

How dd-trace Works

dd-trace is a per-language SDK that runs inside your application, captures spans, and ships them through the Datadog Agent over a proprietary HTTP API to Datadog's backend. There's a separate package per language:

Newer support also exists for C++, Rust, Android, and iOS, but the shape is the same in every language — instrumentation runs in-process, talks to the Agent locally, and the Agent talks to Datadog.

The application never talks to Datadog's backend directly, and the destination is hard-coded by design. Whichever language SDK you use, changing where traces go means swapping the SDK out, not redirecting traffic to a different endpoint.

How dd-trace Makes Tracing Harder Than It Should Be

Beyond the bill and the lock-in, dd-trace quietly costs engineering time because each language SDK was built around Datadog's pipeline rather than a shared open standard, so the same product behaves differently across your stack and the rules aren't always obvious until something breaks in production.

Each language has different problems with dd-trace, and Node.js applications encounter the majority of them. There, dd-trace uses runtime patching to attach itself to imports and assumes the library loads before anything else, an assumption that modern Node setups (ESM imports, webpack, esbuild, Next.js, Nest.js) violate in different ways, with fixes scattered across fragmented docs.

Python has two valid entry points, ddtrace-run and import ddtrace.auto, and you have to pick one per process, using both at once is what causes duplicate-span confusion. PHP needs the ddtrace extension installed through Datadog's datadog-setup.php installer before auto-instrumentation does anything, .NET auto-instrumentation requires either the machine-wide installer or the per-app Datadog.Trace.Bundle package plus a set of environment variables set on the target process (neither of which is obvious from a NuGet add package alone), and Go now supports compile-time auto-instrumentation through Orchestrion, though teams still on the older manual path have to add per-package imports and a tracer.Start() call.

Cutting across all of this, configuration precedence is language-specific. In most SDKs the DD_* environment variables take effect last and override what code sets, so the service name your application thinks it's emitting isn't always what shows up in Datadog. The exact rule varies per language, so the reliable answer is to check the per-language SDK docs before assuming env vars win.

These are small problems on their own, but they add up to engineers debugging the tracer instead of the application. OpenTelemetry doesn't escape complexity entirely, but its instrumentation model is shared across languages and maintained by an open community, so the friction lives somewhere you can find documentation for, not in one vendor's release notes.

dd-trace vs OpenTelemetry

Every difference below clearly shows how dd-trace is built for Datadog's pipeline, while OpenTelemetry is built as an open standard that any backend can implement.

Whether you stay on dd-trace or move to OpenTelemetry comes down to portability. dd-trace works only with Datadog while OpenTelemetry works with any compatible backend, so teams that expect to stay on Datadog indefinitely can keep dd-trace, and teams that want flexibility, lower cost, or independence from a single vendor's roadmap end up moving to OpenTelemetry.

When to Replace dd-trace with OpenTelemetry

The most common reason teams move off dd-trace is cost. Datadog APM pricing starts at $31 per host per month, with APM Pro at $35 and APM Enterprise at $40, before per-span ingestion or indexing overages. At 100 hosts on the base APM plan, that's $3,100/month for APM alone. Moving to an OpenTelemetry-native backend usually drops that bill noticeably, especially at higher host counts.

At scale, the remaining reasons start to matter as much as the bill itself. Once your tracing code uses OpenTelemetry instead of dd-trace, you can point traces at any backend by changing a single endpoint, which dd-trace simply doesn't allow. OpenTelemetry is also the open standard the industry has settled on, so most new instrumentation work goes into OTel rather than vendor-specific SDKs. Separately, Datadog's custom metrics billing is driven by tag-combination cardinality, so rich application tags like customer_id or request_id can compound the metrics line on the invoice even when APM costs are held flat.

If any of these apply, the swap itself is straightforward. For each language, you uninstall the dd-trace package, install the equivalent OpenTelemetry SDK, swap the DD_* environment variables for OTEL_*, and point the OTLP exporter at your new backend.

SigNoz Is Where Most dd-trace Migrations Land

The dd-trace to OpenTelemetry swap is the easy part. The harder question is which OTel backend the traces actually go to once dd-trace is out, the practical reasons teams coming off Datadog end up on SigNoz come down to the following.

Your Datadog Muscle Memory Carries Over

SigNoz's UI is built around the same primitives a Datadog user already knows. Trace waterfalls, service maps, the log explorer, and the query builder map closely to their Datadog equivalents, so the team's existing Datadog muscle memory carries over instead of being thrown away. That tends to keep migration risk lower than picking a tool with a completely different mental model.

Logs, Metrics, and Traces in One Platform

SigNoz keeps logs, metrics, and traces in a single platform with a single query language and a single bill. Pivoting from a trace to its logs to the host metrics behind it happens inside one product, so an incident never turns into a tab-switching exercise across separate tools and the team isn't learning four query languages to answer one question.

Lower Per-GB Pricing, No Per-Host Bills

Datadog APM is billed per host ($31 for APM, $35 for APM Pro, $40 for APM Enterprise, per host per month), so the bill scales with how many machines you run rather than how much tracing data you actually send. SigNoz prices traces at $0.30/GB with no per-host or per-user charges, so the bill is bounded by trace volume alone. Adding hosts, services, or engineers doesn't change the line item.

OpenTelemetry-Native, So There's No Second Lock-In

A few backends accept OTLP traffic but push their own agents or SDKs back onto you for full feature parity. Picking those means trading one lock-in for another, which is exactly what you were trying to avoid when leaving dd-trace. SigNoz is built on OpenTelemetry from the ground up, so the instrumentation work you do for SigNoz keeps working with any other OTLP-compatible backend if you ever switch again.

For the destination choice in more depth, see How to Migrate from dd-trace to OpenTelemetry (and Why Teams Pick SigNoz).

Migration Tooling Actually Built for This Move

Most OTel destinations leave the migration entirely up to you. SigNoz ships a Datadog dashboard JSON migrator that converts your existing Datadog dashboards into SigNoz dashboards in one step, supports the open-source OpenTelemetry Datadog Receiver so you can forward Datadog Agent traffic to SigNoz while you swap SDKs at your own pace, and publishes per-language migration documentation for every dd-trace variant. The combined effect is that staged migrations stay in production-readable shape from day one rather than going through a long cutover.

FAQs

What does dd-trace do?

It's Datadog's tracing SDK, hard-wired to the Datadog Agent. SigNoz Cloud uses the OpenTelemetry SDK instead, so the same spans land in an OTel-native backend.

Is ddtrace the same as dd-trace?

Yes, just spelled differently per ecosystem. Python uses ddtrace, Node.js uses dd-trace.

Is dd-trace open source?

Source is on GitHub but the protocol and backend are Datadog's. SigNoz Cloud is OpenTelemetry-native end to end, no translation layer needed.

Does dd-trace work with OpenTelemetry?

Partially. It accepts OTel spans and supports W3C Trace Context, but full OTel means replacing dd-trace with the OTel SDK and pointing it at SigNoz Cloud or any OTLP backend.

Is there a free Datadog option?

No free tier for Datadog APM. SigNoz Community Edition (open-source, self-hosted) and SigNoz Cloud's free trial are the two simplest free paths.

Which package do I install for my language?

Python: ddtrace. Node.js: dd-trace. Go: dd-trace-go. Java: dd-java-agent.jar. Ruby: datadog gem. .NET: Datadog.Trace.Bundle. PHP: datadog-setup.php. Replacing them with the OTel SDK is what unlocks SigNoz Cloud as the destination.

Can I run dd-trace without the Datadog Agent?

No. dd-trace only talks to the Datadog Agent. SigNoz Cloud uses the OpenTelemetry Collector, which has no such pinning.

How do I move my services off Datadog's dd-trace SDK to OpenTelemetry?

Uninstall dd-trace, install the OpenTelemetry SDK, swap DD_* env vars for OTEL_*, and point the OTLP exporter at SigNoz Cloud. Per-language steps are in the migration guide linked at the top.