Datadog vs OpenTelemetry: When to Drop the Agent

Three years ago, "use the Datadog agent" was the only answer if you wanted Datadog APM to work. The agent was a proprietary trace collector with framework-specific patches, a battery of integrations, and a wire format only Datadog understood.

That's no longer true. As of 2026, Datadog accepts OTLP — the OpenTelemetry wire format — directly. You can install the OpenTelemetry Node SDK (@opentelemetry/sdk-node), point its OTLP exporter at Datadog, and your traces show up in the Datadog UI exactly as they would have with the agent. Same dashboards. Same alerts. Same flame graphs.

So why does anyone still use the agent? Three reasons — and only one of them is a good reason for most teams.

The 90% overlap

For traces specifically, the OpenTelemetry SDK and the Datadog agent now do roughly the same thing. Both:

• Patch HTTP client and server libraries to capture spans automatically
• Patch database drivers (Postgres, MySQL, MongoDB, Redis) for query timing
• Capture exceptions and link them to the active span
• Propagate trace context across async boundaries
• Export over OTLP / HTTP

The OpenTelemetry coverage is now strictly a superset for many Node frameworks: Hono, Polka, Feathers, h3, and several smaller frameworks have community OTel instrumentation but no Datadog tracer. If you use anything outside the top-5 web frameworks, OTel often gets you better coverage than the Datadog agent.

Where the agent still wins

There are three honest reasons to keep the Datadog agent:

1. Network Performance Monitoring (NPM). The agent uses eBPF to capture kernel-level network metrics — TCP retransmits, DNS resolution latency, per-connection bytes — that OpenTelemetry cannot capture from userspace. If you actually use NPM for incident response (most teams don't), the agent stays.

2. Continuous Profiler. Datadog's continuous profiler ships with the agent and produces flame graphs for CPU, memory, and lock contention without code changes. There are OpenTelemetry equivalents (Pyroscope, Parca, Grafana Pyroscope) but they're separate products you'd run alongside.

3. Cloud Workload Security / CSPM. If you're using Datadog's security products that snapshot the host filesystem and process tree, the agent is mandatory because it runs at root.

For pure APM and logs — which is what 80% of teams use Datadog for — the agent has no functional advantage over OpenTelemetry as of 2026.

The lock-in math

The reason this matters isn't technical, it's commercial. With the Datadog agent installed everywhere, switching costs include:

• Removing agents from every pod / VM / serverless function
• Re-instrumenting any custom traces written against the proprietary dd-trace API
• Re-implementing log sourcing because the agent's log forwarder has Datadog-specific tagging conventions
• Adapting alerts that reference Datadog-specific metric names

With OpenTelemetry as the data layer, switching costs are: change one config value (the OTLP endpoint URL). Your application code, custom spans, and instrumentation are unchanged. This is the asymmetric reason to migrate the data layer first, even if you keep Datadog as the destination.

In practice, teams that adopt this pattern report two outcomes: (a) they rarely actually leave Datadog, but (b) the constant credible threat of leaving keeps their renewal pricing 20–40% lower than peer companies.

How to migrate without downtime

A practical path used by several teams I've talked to:

Stage 1 — Add OTel alongside the agent. Install @opentelemetry/sdk-node and configure it to export to a local OpenTelemetry collector. The collector forwards to Datadog. The agent is still installed and running. Traces show up twice in Datadog (one set from the agent, one from OTel) — annoying, but harmless. Verify the OTel traces look correct.

Stage 2 — Disable the agent's tracer. Set DD_APM_ENABLED=false on the agent. Now the agent only handles process metrics + log forwarding. Your traces are 100% OTel, still landing in Datadog.

Stage 3 — (Optional) Replace log forwarding. If you want to leave the agent entirely, configure your application's log output to go directly to OpenTelemetry's log SDK, which exports to OTLP. The agent can now be uninstalled.

Stage 4 — (Optional) Change destinations. With OTLP as the wire format, point the exporter at SigNoz, Grafana Tempo, SecureNow, or any OTLP-compatible backend. Your application code is unchanged.

Most teams stop at Stage 2. The savings come from leverage in renewal negotiations, not from actually leaving.

The Node-specific wrinkle

Node.js has one OTel quirk worth knowing: auto-instrumentation requires a --require (or -r) flag at process start. The Datadog agent doesn't need this because it loads from dd-trace as a regular import. With OTel, you either:

• Add node -r @opentelemetry/auto-instrumentations-node/register your-app.js to your start command, or
• Use a SDK that wraps the boilerplate (e.g., node -r securenow/register your-app.js does the same thing plus adds firewall and AI investigation)

If your start command is in a Dockerfile or PM2 config, this is a one-line change. If it's in a managed platform (Vercel, Railway, Render), you may need their equivalent of NODE_OPTIONS='-r ...' — every modern platform supports it.

The actual recommendation

If you're starting a new project: use OpenTelemetry from day one, regardless of where you send the data. The marginal cost is zero and you preserve every future option.

If you have an existing Datadog deployment: add OTel alongside the agent for new services first. Don't try to convert everything at once. Six months later you'll have a hybrid stack, and at that point migration is a config change rather than a rewrite.

If your bill is the issue: migrate the data layer first (OTel), then shop for a destination. The exercise of standing up the data layer reveals which Datadog features your team actually uses, which is the input to the destination decision.

For a deeper look at what an OpenTelemetry-native destination looks like, see the APM + security combined approach or the Datadog comparison page.

Related

• Datadog real-bill migration story
• SecureNow vs Datadog
• Application security monitoring with OpenTelemetry