Open-source alternative to Datadog APM

Open-source alternative to Datadog APM: the short answer

If you pay Datadog APM per host and your renewal or host count is pushing the bill up, you can replace traces, service maps and latency and error views with a self-hosted stack. The two practical routes are SigNoz, which keeps traces, metrics, logs and alerts in one application backed by ClickHouse, or a Grafana, Prometheus and Jaeger stack fed by OpenTelemetry. In both cases your services are instrumented with OpenTelemetry SDKs and the Collector, so the instrumentation work is portable and the backend becomes a choice you can change later.

A point that often causes confusion during a renewal: the Datadog Agent source code is open (its user space components are Apache-2.0 and its eBPF code is GPL-2.0), but the Datadog backend and UI are not. Replacing the agent does not replace the APM backend, and OpenTelemetry does not replace it either, because OpenTelemetry is a framework for generating and collecting telemetry, not a place to store or query it. The backend decision is the one that determines your storage, query, retention and staffing costs, so make it explicitly rather than assuming the agent swap covers it.

Before you commit, confirm with the vendors and in your own environment how each candidate handles the APM features your teams rely on today, such as flame graphs, service dependency maps, error grouping and retention windows. Check the SigNoz licensing split if you plan to use enterprise-only features, and confirm which Grafana or Jaeger components your team will operate. Your current Datadog APM bill, host inventory and most-used views are the inputs that make the comparison concrete.

Which open-source option covers each Datadog APM capability

This table maps each Datadog APM capability to SigNoz, a Jaeger and Grafana stack, and OpenTelemetry SDKs, with gaps marked where a source does not confirm parity. Read the cells as a starting checklist: where a cell says to confirm, test that feature in your own environment against the current release before you commit.

Capability	SigNoz	Jaeger with Grafana	OpenTelemetry SDKs and Collector
Distributed traces	Traces are collected by the SigNoz OpenTelemetry Collector and stored in ClickHouse, with APM and distributed tracing listed as features	Jaeger is an Apache-2.0 tracing backend, and Grafana can query it as a data source	Trace APIs and SDKs are stable in Go, Java, Python, .NET, JavaScript and other languages, per the OpenTelemetry status page
Service maps and dependency views	Listed as part of APM; confirm the depth of the map and its behavior at high service counts	Jaeger ships its own trace UI with dependency views; confirm what the current v2 release provides	Not a backend feature; depends on the receiving backend
Latency and error views	APM views are documented; confirm percentile, error rate and endpoint breakdowns in the current release	Jaeger shows span durations and errors; percentile dashboards need Prometheus metrics or span-derived metrics built by your team	Span status and duration are emitted by SDK instrumentation, so coverage depends on the libraries you enable
Trace search and retention	Query Builder and ClickHouse SQL search traces; retention is set by your own storage and configuration	Search depends on the storage backend you choose; retention and index sizing are your responsibility to plan	Not applicable; the Collector only routes data
Dashboards and queries	Dashboards built with Query Builder, PromQL or ClickHouse SQL	Grafana dashboards query Jaeger and Prometheus data sources; Grafana is AGPL-3.0-only	Not applicable
Alerting	Alertmanager handles deduplication, grouping and notification; confirm rule types for trace-based alerts	Grafana alerting can use Prometheus-derived metrics; trace-based alerts usually need span metrics first	Not applicable
Tail sampling	Confirm whether sampling policies can be applied at the Collector in your deployment	Confirm whether your Collector pipeline performs tail-based sampling before export	Available as a Collector processor in contrib builds; confirm the component stability level in its README
Profiling	Confirm whether continuous profiling is offered in the current release; do not assume parity	Not provided by Jaeger; use a separate profiling tool	Profiling signal maturity is tracked separately in the OpenTelemetry status page; confirm before adoption
Instrumentation libraries	Accepts OpenTelemetry data from many sources; confirm the native Datadog tracer compatibility path	Accepts OpenTelemetry data; the Collector Datadog receiver can bridge during cutover	Language SDKs and auto-instrumentation libraries replace Datadog tracers; coverage per framework must be checked

SigNoz, Grafana with Jaeger, or both: when each fits

Both paths take in OpenTelemetry data, so the choice is about how much you want in one product and how much you are willing to assemble and operate yourself. SigNoz keeps APM, traces, logs and alerts in one application, while Grafana with Jaeger splits the job across separate components with their own licenses, storage and upgrade cycles.

SigNoz as one integrated platform

SigNoz keeps APM, distributed tracing, logs, metrics and alerts in one application, which is the main reason teams pick it over a stack of separate tools. Its components are the SigNoz OpenTelemetry Collector, which writes to ClickHouse, an API server that serves the React frontend and query APIs, and Alertmanager for deduplication, grouping and notification. Check that your team can operate ClickHouse, since storage sizing and upgrades fall to you when you self-host.

SigNoz licensing and enterprise directories

The SigNoz core outside the ee/ and cmd/enterprise/ directories is MIT licensed, and code inside those directories falls under a separate enterprise license. Before you deploy, confirm which features you need sit in the MIT core. The pricing page also lists SAML as unavailable on the free Community Edition, so identity requirements can decide the edition for you.

Grafana with Jaeger as separate components

A Grafana and Jaeger stack puts Jaeger, an Apache-2.0 CNCF graduated tracing backend, beside Grafana for dashboards. Jaeger v2 is built on OpenTelemetry Collector components, which keeps the ingest path consistent with the rest of your pipeline. Metrics and logs usually come from Prometheus and Loki, so you run and upgrade each one yourself.

Grafana AGPL-3.0 and production database

Grafana moved from Apache-2.0 to AGPL-3.0-only in 2021, so review how AGPL terms apply to your internal use and any modifications you ship. For production and high availability, Grafana needs MySQL 8.0 or later or PostgreSQL 12 or later, since SQLite is not suitable at scale. Plan for the database as a service you back up and patch.

Trade-off of integration versus assembly

One product means one upgrade path, one data model and one place to troubleshoot, but you accept its storage engine and its release cadence. Separate components let you swap parts and reuse existing Prometheus or Loki investment, but each boundary adds a configuration, a version match and a failure mode. Ask which option gives your on-call team fewer moving parts for the signals you actually need.

Running both during evaluation

Because both paths accept OpenTelemetry data, a team can send the same traces to a SigNoz test instance and to a Grafana with Jaeger stack during evaluation. Compare trace search, service maps and alert behavior against real service traffic in your own environment. Confirm retention, query latency at your span volume and the operator effort each setup needs before you choose.

How OpenTelemetry instrumentation replaces Datadog APM libraries

OpenTelemetry replaces the Datadog APM libraries by moving instrumentation into vendor-neutral SDKs inside your applications. Each service emits traces through an OpenTelemetry SDK, which sends them over OTLP to an OpenTelemetry Collector. The Collector runs either as an agent next to each workload or as a gateway that accepts data from many services, and it exports to whichever backend you choose, such as SigNoz, or Jaeger with Prometheus and Grafana. Because the Collector is the routing point, changing or adding a backend during migration means editing the Collector configuration, not re-instrumenting every service. The Collector repository is licensed under Apache-2.0, so the component that sits between your code and your backend carries no licensing cost.

Maturity varies by component, and your inventory should reflect that before you commit. Trace APIs and SDKs are stable in most languages, including Go, Java, JavaScript, Python, .NET and Ruby, according to the OpenTelemetry status page. Log SDK maturity varies more, with several languages still in development, so plan for Datadog log shipping to remain in place or move on a separate track. The same status page documents that core Collector components have mixed stability levels, so check the README of each receiver, processor and exporter you configure. Confirm the stability level of every component in your pipeline, and record it in the migration plan.

Securing the pipeline is a configuration task you own. Collector authenticator extensions can check credentials on incoming connections at receivers, for example with OIDC, and attach credentials to outgoing exporter requests, for example with the oauth2client extension. Review the Collector configuration best practices before exposing a gateway to other networks, and make sure receivers do not listen on interfaces they do not need. Decide who owns the Collector configuration, and treat it as code under change control, since a gateway that accepts traces from every service is a shared attack surface.

Which trace features need extra work when you run the backend

Instrumenting with OpenTelemetry moves the agent side of APM out of Datadog, but the trace backend, its storage, its availability and its security settings become your job. The cards below cover the areas where a self-hosted SigNoz or Grafana and Jaeger stack needs deliberate planning, and what to confirm against current vendor documentation before you commit.

Trace retention and storage sizing

Datadog bills APM per host and keeps trace retention inside the service, so storage growth is not your problem today. Self-hosted, you own the disk or object store that holds every span you keep. Decide retention per service and per environment, and estimate storage from your own span volume in a test cluster before choosing a retention window. Check how SigNoz's ClickHouse storage and Jaeger's storage backend handle compression, TTL and tiering in the versions you plan to run.

High availability and scaling

The trace pipeline has several moving parts: the ingest collector, the storage cluster, the query API and the frontend. Each needs its own sizing and failure plan, and an outage in the backend means lost or delayed traces unless the Collector buffers them. Confirm how the chosen platform scales ingest horizontally, how replicas and quorum work for its storage, and what happens to in-flight data during a node loss. Plan load tests before cutover, not after the first incident.

Sampling strategy

Datadog offers ingestion and retention controls that many teams use to limit trace volume, but self-hosted, sampling decisions also decide your storage bill and your ability to debug rare errors. Head-based sampling is simple but drops error traces unless you keep errors deliberately. Tail-based sampling in the OpenTelemetry Collector keeps complete traces for slow or failing requests, but it needs a gateway tier that sees whole traces and adds memory cost. Write the policy down with your service owners before turning it on.

SSO and SAML on the free edition

Access control is often the first gap that surprises teams. SigNoz lists SSO on every plan, including Community, but SAML is only on its paid Teams and Enterprise plans. Grafana's authentication docs place SAML, team sync and SCIM in Grafana Enterprise and Grafana Cloud. If your identity provider requires SAML, the free edition may not meet policy, and you should decide between a paid tier, an OIDC or OAuth path, or a proxy in front of the UI. Confirm the current edition matrix with each vendor before you design around it.

Service map and dependency analysis

Service maps in Datadog are generated from traces it ingests and shown without configuration. In a self-hosted stack, the map depends on consistent service names, span kinds and attributes across every instrumented service, plus a backend that can aggregate dependencies over time. Inconsistent naming is the usual cause of a broken map. Audit instrumentation coverage for each language and framework, and test the map against a known call graph before relying on it for incident response.

Upgrades and backups

Datadog patches its backend for you. Running the stack yourself means you schedule upgrades for the Collector, the query layer, the storage engine and the dashboard tool, and you back up trace storage, dashboard definitions and alert rules. Pin versions, read release notes for breaking changes in the Collector configuration, and rehearse a restore from backup on a separate cluster. Grafana publishes an upgrade cadence and support windows, and SigNoz and the OpenTelemetry Collector publish releases you should track.

Migrating APM traffic from Datadog to a self-hosted backend

This sequence moves application traces, service maps and latency and error views from Datadog APM to a self-hosted backend without a gap in visibility. Each step ends with a check that the new backend shows the same behavior as Datadog before the next step begins.

Inventory services and Datadog APM hosts
The platform or APM owner lists every service that reports to Datadog APM, the language and tracing library each one uses, the hosts and containers they run on, and the Datadog APM host count that drives the bill. Include services that are reported only through the Datadog Agent's trace port and any custom span tags that dashboards or monitors depend on. The step is done when the inventory names an owner for each service and the list of tags to preserve is agreed with the teams that read those dashboards.
Instrument services with OpenTelemetry
Service teams replace Datadog tracing libraries with OpenTelemetry SDKs or auto-instrumentation for each language, and map Datadog span names, service names and environment tags to OpenTelemetry resource attributes. Where a Datadog-specific feature has no direct OpenTelemetry equivalent, record the gap in the inventory rather than guessing a substitute. The step is done when each service emits traces to a local OpenTelemetry endpoint in a non-production environment and a sample trace shows the expected service and operation names.
Deploy the OpenTelemetry Collector
The platform team installs the OpenTelemetry Collector as an agent beside services or as a gateway that receives data from many sources, then configures a pipeline with OTLP receivers and two exporters: one to Datadog through its documented OTLP path and one to the self-hosted backend. Protect the receivers with authentication where the deployment requires it, and keep credentials out of configuration files. The step is done when the Collector reports healthy in its own telemetry and both exporters show accepted spans in staging.
Stand up the self-hosted backend in staging
The platform team deploys the chosen backend, such as SigNoz with ClickHouse or a Grafana and Jaeger stack, in a staging environment that matches production sizing assumptions. They configure storage, retention, authentication, backups and access control before any production traffic arrives, and they confirm the vendor's current install path and supported versions in its documentation. The step is done when staging receives traces from the Collector, a restore from backup has been tested, and the team has written down who operates upgrades.
Dual-ship traces and rebuild dashboards and alerts
With both exporters running in production, the team sends the same traces to Datadog and to the self-hosted backend. Export existing Datadog dashboard definitions as JSON to use as a reference, then rebuild service views, latency percentiles, error rates and service maps in the new backend, and recreate APM monitors as alert rules with the same thresholds and notification routes. The step is done when each rebuilt dashboard has a named owner and each migrated alert has been tested by triggering it in staging or with synthetic load.
Validate latency and error views against Datadog
Engineers compare the same services, time windows and endpoints in Datadog and in the self-hosted backend, checking request counts, latency percentiles, error counts, and the presence of upstream and downstream dependencies in the service map. Differences are logged with the cause, such as sampling settings, span naming or missing attributes, and fixed before cutover. Expect some differences in how each product computes percentiles and sampling, and confirm the methodology for each metric with the vendor documentation. The step is done when the agreed comparison list shows no unexplained gaps for production services.
Cut over and decommission Datadog agents
The team removes the Datadog export from the Collector pipeline once the validation list is closed, switches the service-facing alerts and on-call rotations to the self-hosted backend, and then removes the Datadog tracing libraries and Agent trace collection from each host. Keep the Datadog subscription active for an agreed period so that historical comparison remains possible, and record the date each host stops sending APM data. The Datadog Agent's Apache-2.0 user space code and GPL-2.0 eBPF code do not change this dependency: the Agent may be removed or retained for infrastructure checks, but the APM backend is still Datadog until the Collector pipeline stops exporting to it. The step is done when no service sends APM data to Datadog and the change record lists each decommissioned component.

Self-hosting SigNoz versus SigNoz Cloud versus a Grafana stack

The Community Edition is the free, self-hosted path. SigNoz documents installation with Docker Standalone, Docker Swarm and Kubernetes with Helm, and its pricing page says the Community Edition includes APM and tracing, log management, infrastructure monitoring, alerting and LLM monitoring. Software licensing costs nothing, so the spend is infrastructure and people. Your team owns the Collector fleet, the ClickHouse storage behind it, retention, upgrades and backups.

Software fee: The Community Edition has no license charge, according to the SigNoz pricing page.
Deployment options: Docker Standalone, Docker Swarm and Kubernetes with Helm, per the SigNoz self-host install docs.
Excluded features: SAML, SOC 2 and HIPAA compliance, anomaly detection and prebuilt integrations are not included, according to the SigNoz pricing page.
Support model: Community Slack only, according to the SigNoz pricing page.
SSO: Listed on every plan, including the Community Edition, but SAML needs the Teams or Enterprise plan.

Recurring costs are compute, ClickHouse storage, backups and engineer time for upgrades. Confirm with SigNoz which Community features match your APM needs before you rely on them, and ask who on your side will hold the on-call duty for the stack.

Questions buyers ask before replacing Datadog APM

What drives the cost of self-hosting APM instead of paying Datadog per host?

The cost depends on how much telemetry you generate, how long you keep it, and how many people run the stack. Self-hosting moves spending from a per-host subscription to compute and storage for the trace backend, plus staff time for upgrades, backups, scaling and on-call. Datadog's US pricing list shows APM at $31 per APM host per month billed annually, or $36 month-to-month and on demand, which gives you a baseline to compare against. Ask your team to measure current host count, span volume and retention so the comparison uses your own numbers, not a generic estimate.

Which costs are one-time and which recur after a self-hosted APM stack goes live?

One-time costs include designing the OpenTelemetry instrumentation, building the Collector pipeline, rebuilding service maps and latency views, and running both systems in parallel during cutover. Recurring costs include infrastructure for the trace backend and its database, object storage if you use it, security patching, version upgrades, backups and the on-call time that the platform needs. Some backend options also have paid support tiers. For example, SigNoz Enterprise starts at $4,000 a month if you buy managed or supported delivery instead of running the Community Edition yourself. Confirm which recurring items your chosen option includes before you compare totals.

How long does migrating Datadog APM to OpenTelemetry take?

The duration is set by the number of services, the number of languages in use, and how many custom spans, tags and monitors depend on Datadog-specific libraries. Services that already use OpenTelemetry SDKs move faster than services instrumented with the Datadog tracing libraries, which must be replaced. Dual-shipping telemetry to both Datadog and the new backend lets you compare results before cutover, but it adds months of overlapping cost if it runs long. No supplied figure gives a fixed timeline, so ask any partner to break the schedule into service waves and to state the assumptions behind each wave in the written scope.

What does the internal team need to provide for an APM migration?

Your team needs an inventory of services and their languages, owners who can confirm expected behavior, access to the production and staging environments, and someone who can approve changes to application deployments. Platform or SRE staff need to run the Collector, the trace storage and the backing database, which includes capacity planning, retention settings and backup restore tests. Engineers who own each service must review their spans, attributes and sampling choices. Confirm named owners for each of these roles before work starts, because delays usually come from unavailable service owners rather than from the tooling.

Can our engineers migrate Datadog APM to SigNoz or a Grafana and Jaeger stack themselves?

Yes, if your team already runs Kubernetes or Docker in production and has experience with observability backends. SigNoz documents self-hosted installation with Docker Standalone, Docker Swarm and Kubernetes with Helm, and Jaeger is Apache-2.0 licensed and a graduated CNCF project, so the building blocks are available without a license fee. The harder work is consistent instrumentation across services, trace context propagation, and reproducing alerts and service maps. Teams without that experience often choose a fixed-scope engagement for design and handover, and keep the routine operation in-house.

Which trace features need extra work when we run the APM backend ourselves?

Service maps, latency percentiles, error grouping and trace search are available in SigNoz and in Grafana with Jaeger, but they depend on consistent span naming, attribute conventions and sampling decisions that you must set yourself. Features that Datadog provides out of the box, such as prebuilt integrations and anomaly detection, may need configuration or may be absent in the free edition. The SigNoz pricing page says the Community Edition does not include anomaly detection or prebuilt integrations. Check each feature on your list against the chosen platform's documentation before you commit to a scope.

What should we ask a partner for in a fixed-scope quote for APM migration?

Ask for a written scope that lists the services, languages and environments covered, the trace features to be rebuilt, and the dashboards and alerts to be recreated. The quote should name deliverables such as Collector configuration, instrumentation changes, backup and restore testing, runbooks and handover sessions. It should also state which items are excluded, how dual-running is handled, who operates the platform after go-live, and what a retainer for upgrades and support would cover. DeployOpen plans and implements these systems in your own infrastructure and prepares the evidence for compliance reviews, but it does not issue audit reports or certifications. Ask for the scope and the schedule in writing before work starts, since DeployOpen agrees both before engagements begin.

How DeployOpen scopes and delivers an APM replacement

DeployOpen plans and implements self-hosted open-source observability platforms inside your own cloud accounts, data centers or air-gapped networks. For an APM replacement, we start from a written scope that names the services, languages and trace features in use, then build the OpenTelemetry instrumentation and backend alongside your current Datadog APM so you can compare results before cutover.

How we scope

Inventory the services, languages and Datadog APM features in use, including service maps, latency and error views.
Confirm the target backend, such as SigNoz or a Grafana and Jaeger stack, and where it will run.
Agree deliverables, timelines and responsibilities in writing before any work starts, as all engagements are fixed-scope.

How we build

Instrument services with OpenTelemetry SDKs and deploy the OpenTelemetry Collector as an agent or gateway in your environment.
Configure the trace backend, storage, retention and access controls, and check trace features that need extra work to rebuild.
Test trace ingestion, dashboards and alert paths against the live services during a parallel run before any switch.

How we hand over

Document the architecture, configuration, instrumentation standards and runbooks for your platform and operations teams.
Provide the evidence and control records your compliance assessors may ask for, while noting that independent auditors issue any attestations.
Walk your engineers through dashboards, trace queries and upgrade steps so the team can run the platform without us.

How we support

Ongoing support, upgrades, backups and continuous testing are available as a retainer after handover.
Retainers can cover upgrades of the backend and Collector, which release frequently and need staged testing.
Ask for the support scope, response expectations and escalation path in the written quote before committing.

Open-source alternative to Datadog APM