Open-source Datadog alternatives in 2026

If you want to leave Datadog for something open source, there are four shapes to choose between, not fifty products: the Grafana LGTM stack (Loki, Grafana, Tempo, Mimir), a single OpenTelemetry-native backend on ClickHouse (SigNoz, Uptrace, HyperDX), an object-storage-first engine (OpenObserve), or the VictoriaMetrics family (VictoriaMetrics, VictoriaLogs, VictoriaTraces). Everything else is a variation on one of those, or a classic DIY assembly of Prometheus, Grafana, Jaeger and an Elasticsearch-compatible log store.

Picking between them is not really a feature comparison. All of them ingest OpenTelemetry, all of them draw charts, all of them alert. The thing that differs by an order of magnitude is how much of your week the stack takes, and where it fails at 3am. This post is a map of the options by that axis.

Upfront disclosure, because it changes how you should read the recommendations: we build TracePath, a commercial hosted observability platform. It is not open source and it is not in the survey below. It shows up once, at the end, in the section about when a hosted product is the honest answer.

Key takeaways

• Open source does not mean free. It means you pay in engineer-hours, storage, and an on-call rotation for the observability stack itself.
• Component count is the best single predictor of operational weight. Four stateful systems with four query languages is a different job from one binary plus a database.
• Licences and editions vary and change. MIT, Apache-2.0 and AGPL-3.0 all appear in this landscape, sometimes with a separate enterprise edition for the clustering or SSO features you will eventually want. Check the licence of the exact component and edition before you commit — this post was verified in September 2026.
• Cardinality is the cost driver nobody budgets for. A well-meant user_id label can multiply a metrics bill, or a self-hosted node count, by an unpleasant factor.
• Instrument with OpenTelemetry regardless. OTLP is the one decision in this space that is genuinely reversible: the exporter endpoint is a config value, and every option here accepts it.

First, decide what you are optimising for

Three questions, answered honestly, narrow the field faster than any feature matrix:

1. Do you have a platform team? Not "could someone learn Kubernetes" — do you have people whose job includes owning stateful infrastructure? If not, anything with four stateful components is a trap, no matter how good it is.
2. What is the failure mode you cannot accept? Losing a week to a storage migration? A surprise invoice? Not being able to answer a question during an incident? Each option here is bad at a different one of those.
3. How long do you actually need the data? Retention drives storage, and storage drives everything else. Most teams need days of high-fidelity data and months of aggregates, and pay for months of high-fidelity data because nobody set a policy.

The four shapes

1. The Grafana LGTM stack

Loki for logs, Grafana for dashboards, Tempo for traces, Mimir for metrics. Four systems, each with its own query language (LogQL, TraceQL, PromQL), each with its own scaling and failure characteristics, all backed by object storage. The components are AGPLv3.

What it does well: it is the most capable and most widely deployed of the options, and the ecosystem around it is enormous — dashboards, exporters, blog posts, people who have already had your problem. It scales genuinely far, and each component can be scaled independently, which matters when logs grow ten times faster than metrics.

What it costs: you are running four stateful distributed systems. In microservices mode each of those is several deployments. The single-binary modes soften this, but the configuration surface does not shrink — object storage lifecycle rules, compactor settings, ingester replication, retention per tenant, and four sets of upgrade notes.

The 3am failure mode: the query path for the signal you need is down, or slow enough not to matter, and debugging it means understanding that component's internals while an incident is in progress.

Choose it if: you have a platform team, or you are already deep into the Grafana ecosystem and the dashboards are an asset you do not want to rebuild. Our side-by-side with the LGTM stack goes into the component-count trade-off in more detail.

2. One OTel-native backend on ClickHouse

SigNoz (MIT), Uptrace and HyperDX (now developed under ClickHouse) all take the same bet: put logs, traces and metrics in one columnar database, and give them one correlated UI instead of three. ClickHouse is the database in each case.

What it does well: correlation. One store means clicking from a slow endpoint to its trace to the logs emitted inside that trace is a join, not an integration. One query surface means one thing to learn. These are also the most natively OpenTelemetry-shaped options — attributes survive as attributes rather than being flattened into a log line.

What it costs: you are running ClickHouse. That is a real database with real operational requirements: disk sizing, merge behaviour, TTL policies, memory limits per query, and — depending on deployment — a coordination layer plus a relational database for metadata. It is one system instead of four, but it is not a toy.

The 3am failure mode: one store means one blast radius. When the database is unhappy, every signal is unavailable at once, where the LGTM split would have left you metrics while logs were down.

Choose it if: you want the correlated experience of a commercial APM and are willing to own one database to get it.

3. Object-storage-first

OpenObserve (AGPL-3.0) inverts the storage decision: data lands as compressed Parquet in object storage (S3, GCS, Azure Blob, MinIO) with stateless compute on top, so there is no database cluster to keep alive.

What it does well: storage cost and operational simplicity at rest. Object storage is cheap, durable and someone else's problem, and stateless compute means scaling the query tier is boring. For log-heavy workloads where most data is written once and read never, this is a very good structural fit.

What it costs: query latency characteristics are different from a local-disk columnar engine, and tuning is about partitioning and file layout rather than indexes. The operational surface is smaller, but it is also less familiar.

The 3am failure mode: an object-store outage or throttling takes queries with it, and the fix is not in your hands.

Choose it if: logs dominate your volume, your cloud already gives you object storage, and you would rather not run a database.

4. The VictoriaMetrics family

VictoriaMetrics for metrics, VictoriaLogs for logs, VictoriaTraces for traces; the community editions are Apache-2.0, with a separate enterprise edition. The project's consistent theme is resource efficiency: less RAM and disk for the same data than the obvious alternative.

What it does well: metrics, extremely well, with Prometheus compatibility that makes migration off a Prometheus setup nearly free. VictoriaLogs is a serious log store rather than an afterthought. If your existing pain is "our Prometheus keeps falling over", this is the shortest path.

What it costs: it is still multiple components if you want all three signals, and the correlated-UI experience is less integrated than the single-backend options. Some features live in the enterprise edition.

The 3am failure mode: the same as LGTM's, scoped smaller: per-signal availability, per-signal debugging.

Choose it if: metrics are the centre of gravity and efficiency at scale matters more than a unified UI.

The DIY baseline

Prometheus plus Grafana plus Jaeger plus an Elasticsearch-compatible log store is still a perfectly reasonable stack, and for many teams it is the one already running. It is worth naming because it sets the floor: if what you have works, "migrate to a better open-source stack" needs a concrete problem behind it, not a comparison table.

What open source actually costs

The comparison that matters is not licence fee versus subscription. It is total cost, and four line items dominate it.

Engineer-hours. Initial deployment is the small part. The recurring cost is upgrades, capacity changes, schema or index migrations, and the investigation that happens the first time a query gets slow. A conservative estimate for a multi-component stack is a meaningful fraction of one engineer, permanently.

Storage, and therefore retention. Every option here will happily store more than you need. Without an explicit retention policy per signal, the stack grows until something breaks, and the emergency fix is always deleting data you wanted. Decide up front: how many days of raw traces, how many days of raw logs, how many months of metric rollups.

Cardinality. The number of unique label or attribute combinations is what determines metrics cost, in every system, self-hosted or not. One customer_id label on a high-traffic metric is the difference between a comfortable deployment and an emergency. This is not an open-source problem — it is the reason commercial metrics bills surprise people too — but when you self-host, the surprise arrives as an outage instead of an invoice.

On-call for the observability stack. The uncomfortable one. Your monitoring is a production system, and when it is down you are blind during exactly the incidents you bought it for. Someone has to carry that pager.

None of this means self-hosting is wrong. It means "free" is the wrong word, and the comparison should be made against what those hours are worth.

A decision guide

Your situation	Reasonable choice
Platform team, Kubernetes, existing Grafana investment	LGTM stack
Want correlated logs/traces/metrics, willing to run one database	SigNoz, Uptrace or HyperDX on ClickHouse
Log-heavy, cloud-native, object storage available	OpenObserve
Metrics-centric, Prometheus pain, efficiency matters	VictoriaMetrics family
Working Prometheus + Grafana + Jaeger, no concrete pain	Keep it
No platform team, and observability is not the product	A hosted platform

That last row is the one people argue with, so be specific about it: if nobody on the team wants to own a database, self-hosting does not remove the work, it relocates it to whoever is least able to refuse. The honest comparison is subscription cost versus the fully loaded cost of those hours plus the infrastructure.

Where a hosted platform fits

This is the part where we are not neutral, so here is the disclosure again: TracePath is our product. It is commercial and hosted — not open source, and not an entry in the survey above.

What it is worth knowing regardless of what you choose:

• It is built on OpenTelemetry, and ingest is plain OTLP/HTTP. The same exporters, collectors and SDKs that feed SigNoz or the LGTM stack feed it, so the instrumentation decision is separable from the backend decision.
• That is the whole lock-in argument. Instrumentation is the expensive, code-touching part, and OTLP makes it portable. Dashboards and alert rules are what you rebuild when you move — which is true in every direction, including between two open-source stacks.
• Logs, traces, metrics, exceptions, session replay, profiles, AI tracing, synthetic monitors, status pages and on-call paging sit on one backend, which is the same correlation argument the ClickHouse-backed projects make.

If you want that comparison drawn against the commercial incumbents rather than the open-source field, we keep capability-by-capability pages for Datadog, Sentry, New Relic and the Grafana stack.

FAQ

What is the closest open-source equivalent to Datadog? For a single product covering logs, traces and metrics with one correlated UI, the ClickHouse-backed OTel-native projects are the closest in shape. For breadth of integrations and ecosystem, the Grafana stack is closer. Neither matches Datadog's surface area, and both cost operational time instead of subscription fees.

Can I self-host and still use OpenTelemetry instrumentation? Yes — that is the point of OTLP. Every option discussed here accepts OpenTelemetry data, so the instrumentation in your code does not change when the backend does.

Is AGPL-3.0 a problem for my company? It depends entirely on your legal posture and whether you modify and redistribute the software. Running an unmodified AGPL server internally is normally uncontroversial; embedding modified code in a product you ship is the case to ask about. Get an actual answer from your legal team rather than from a blog post.

How much does self-hosting really cost? Infrastructure is the predictable part and usually the smaller one: a database tier sized for your retention, plus object storage. The variable part is engineer time, and it concentrates in upgrades, migrations and incidents rather than spreading evenly.

Should I run my own collector? Usually yes, regardless of backend. An OpenTelemetry Collector between your services and your backend gives you batching, retry, redaction and the ability to change destinations — including fanning out to two backends during a migration — without redeploying applications.

The short version

If you have a platform team, the LGTM stack is the most capable and the most work. If you want one correlated backend and can own a database, the ClickHouse-native projects are the closest thing to a self-hosted Datadog. If logs dominate and object storage is already in your cloud bill, the object-storage-first design is the cheapest at rest. If metrics are the centre of gravity, the VictoriaMetrics family is hard to beat on efficiency.

And if the answer to "who owns this database?" is a long silence, that is data too. Instrument with OpenTelemetry either way — it is the one part of this decision you can change your mind about later.