TL;DR
SigNoz: OpenTelemetry-native APM with a Datadog-style UI, a Datadog dashboard migrator, and Datadog Receiver support for staged migrations offdd-trace
.Datadog (: 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
)
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:
| Language | Package |
|---|---|
| Python | ddtrace |
| Node.js | dd-trace |
| Go | `dd-trace-go` |
| Java | `dd-java-agent` |
| Ruby | datadog gem |
| .NET | Datadog.Trace |
| PHP | datadog-setup.php |
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.
Already using dd-trace and looking for an OpenTelemetry-native alternative? Try SigNoz Cloud. Same Datadog-style UI, OTLP instead of proprietary protocols.
Get Started - Free 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.
| Aspect | dd-trace |
OpenTelemetry |
|---|---|---|
| Maintained by | Datadog | The CNCF (Cloud Native Computing Foundation) |
| Wire protocol | Datadog Agent protocol (proprietary HTTP API) | |
Context propagationx-datadog-*
headers, current SDKs also extract and inject W3C Trace Context and Baggage by defaultConfigurationDD_*
environment variablesOTEL_*
environment variablesBackendAuto-instrumentationLanguage supportdd-trace
doesn't supportLock-in 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](https://signoz.io/pricing/) 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.
Ready to replace dd-trace? SigNoz Cloud is OpenTelemetry-native, ships a Datadog dashboard migrator, and runs the same workflow at a fraction of the per-host cost.
Get Started - Free 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.