OpenTelemetry vs Proprietary APM Agents: A Benchmark

There's a lot of marketing-grade claims about APM agent performance ("our agent is 10× faster than the competition"). Here are real numbers from a standardized test bed running 4 different APM agents on identical hardware with identical workloads.

The test setup

Workload: A canonical Express app with:

• 4 GET endpoints (varying complexity)
• 2 POST endpoints (with body parsing)
• 1 endpoint making a Postgres query
• 1 endpoint making a Redis call
• 1 endpoint making an outbound HTTP call

Load: 100 sustained RPS over 30 minutes per agent. k6 load test from a separate instance.

Hardware: AWS m5.large (2 vCPU, 8 GB RAM), Amazon Linux 2023, Node.js 20.

Agents tested:

• dd-trace (Datadog) v5.20.0
• newrelic (New Relic) v11.18.0
• @sentry/node v8.20.0
• @opentelemetry/sdk-node v0.51.0 with auto-instrumentations
• Baseline (no agent)

Each test ran fresh — agent installed, server started, k6 hit it. Process memory and request latency captured throughout.

Results: latency overhead per request

Median (p50) and 99th percentile (p99) request latency, in milliseconds, compared to baseline (no agent):

OpenTelemetry has the lowest median overhead. New Relic has the highest p99 overhead (it has more aggressive default capture, including arguments to many functions).

Practical takeaway: all four agents are in the 0.6–1.2ms median range. For most apps this is well under what users perceive. The p99 differences (3–8ms) matter for high-throughput services but rarely break SLOs.

Memory footprint

Resident set size (RSS) at idle and at peak load:

Sentry has the lightest memory footprint of the proprietary agents (probably because it focuses on errors and lighter trace capture). New Relic is the heaviest. OpenTelemetry is in the middle.

For a 30-pod Kubernetes deployment running on m5.large instances, the difference between Sentry (lowest) and New Relic (highest) is roughly 75 MB × 30 = 2.25 GB of memory across the fleet. Whether that matters depends on your headroom.

Cold-start time

How long after node app.js until the server is ready to accept requests:

OpenTelemetry's auto-instrumentation needs to patch every supported framework at boot, which adds 200–300ms vs baseline. New Relic's much-larger overhead comes from initial agent registration with their backend (a synchronous network call).

Cold-start matters most for serverless / Lambda workloads. For long-lived servers (containers, VMs), the difference is paid once and forgotten.

Per-request CPU overhead

CPU time per request, in microseconds:

This is the metric that translates most directly to bill — if your APM agent uses 12% more CPU, your bill goes up 12% (modulo whether your service is CPU-bound vs I/O-bound).

Where each agent leads

Honest summary:

• Lightest overall: Sentry. Lowest CPU overhead and memory footprint. Caveat: it's primarily an errors product, the APM features are less mature than dedicated competitors.
• Most balanced: OpenTelemetry. Mid-pack on memory, lowest median latency, vendor-neutral. The default choice if you're not committed to a specific destination.
• Most feature-rich: New Relic. Heaviest overhead but also the deepest auto-capture (function arguments, custom metrics, distributed tracing).
• Best Datadog ecosystem fit: dd-trace. Mid-pack performance with the tightest Datadog integration.

Caveats

The benchmark has limitations:

Workload specificity. A different app shape (heavier on database, more I/O parallelism, gRPC instead of HTTP) would shift these numbers. The relative ordering tends to hold but absolute values vary.

Sampling. Aggressive trace sampling (1% of requests) drops the OpenTelemetry overhead to roughly half. Same for the proprietary agents.

Network latency. Some agents export spans synchronously by default, others batch. Network latency to the destination affects observed performance under high load.

What to do with this data

The honest answer is that for most apps, agent overhead is a tertiary concern — well behind feature breadth, pricing, and dashboard quality. The differences shown here (millisecond-level) rarely break SLOs.

Where it does matter:

• Serverless cold-start sensitive. New Relic's cold-start tax is real on Lambda. Prefer Sentry or OpenTelemetry for serverless.
• High-RPS services. The CPU overhead difference between OpenTelemetry (+5%) and New Relic (+20%) translates to real fleet cost at high scale.
• Memory-constrained environments. Sentry is the lightest if memory is the constraint.

For most teams: pick based on the destination's features and price, not the agent's overhead. The agent layer is roughly a wash.

Methodology

Test bed Terraform and the load-test scripts will be published in a follow-up post. All measurements are mean of 10 runs per agent, with 30-minute steady-state per run. Variance was under 5% across runs.

Related

• Datadog vs OpenTelemetry: when to drop the agent
• The real Datadog bill
• APM + security in one tool