Open-source alternatives to Datadog: 4 observability tools compared
Every one of these puts your telemetry inside your own network, and what that costs is a storage engine and a query path you now operate, which is easier to underestimate than the user interface. SigNoz/signoz is the one most readers should look at first, because it collects logs, metrics and traces into a single columnar database behind one query surface.
What Datadog does, and why people look elsewhere
Datadog is a hosted observability platform: metrics, logs, traces, dashboards and alerts collected by an agent and OpenTelemetry.
- billing by hosts, ingested logs and custom metrics, which is hard to forecast
- telemetry leaves your network
- proprietary agent and dashboard formats
The candidates at a glance
| Project | Licence | Maintenance | Language | GitHub stars | Install | Best for |
|---|---|---|---|---|---|---|
| SigNoz/signoz | Custom licenceCustom licence: read the LICENSE file | Commits in the last dayLast push October 11, 2026 | TypeScript | 32,328 | See analysis | You already emit OpenTelemetry data and want traces, logs and metrics in one query surface you control, rather than three backends and three UIs. The README covers APM over service latency, error rate, throughput, Apdex, database and external calls, log management with correlation and a visual query builder, infrastructure monitoring for Kubernetes and hosts, LLM observability, and distributed tracing with flamegraphs and waterfalls. |
| grafana/grafana | AGPL-3.0Network copyleft: hosting a modified version means sharing source | Commits in the last dayLast push October 11, 2026 | TypeScript | 77,250 | See analysis | Your metrics, logs and traces already sit in queryable stores and what is missing is a shared view: dashboards with template variables, Explore for ad-hoc queries and drilldown, switching from metrics to logs with preserved label filters, and alert rules with notifications to systems like Slack, PagerDuty, VictorOps and OpsGenie. |
| openobserve/openobserve | AGPL-3.0Network copyleft: hosting a modified version means sharing source | Commits in the last dayLast push October 11, 2026 | TypeScript | 22,317 | Command documented | You want one binary or container that ingests OpenTelemetry data and keeps Parquet files in object storage instead of running a search cluster, with logs, metrics, traces, Real User Monitoring and AI observability behind one UI. The README also describes a service graph, dashboards with template variables and geo maps, and SQL for logs and traces alongside PromQL for metrics. |
| uptrace/uptrace | AGPL-3.0Network copyleft: hosting a modified version means sharing source | Commits in the last six monthsLast push October 8, 2026 | Go | 4,300 | Command documented | You already emit OTLP and want traces, metrics and logs in one self-hosted UI backed by ClickHouse, with users and projects managed through YAML config and single sign-on through OpenID Connect with providers such as Keycloak, Google Cloud and Cloudflare. The README also describes Grafana compatibility, so Grafana can use Uptrace as a Tempo or Prometheus datasource. |
Each alternative in detail
SigNoz/signozSigNoz is an open-source, OpenTelemetry-native observability platform for your team and their AI agents. Get logs, metrics, and traces in one tool with features like APM, distributed tracing, log management, infra monitoring, etc. Combined with SigNoz MCP and a native AI teammate (in SigNoz Cloud) it helps you build more resilient apps.
- Best for
- You already emit OpenTelemetry data and want traces, logs and metrics in one query surface you control, rather than three backends and three UIs. The README covers APM over service latency, error rate, throughput, Apdex, database and external calls, log management with correlation and a visual query builder, infrastructure monitoring for Kubernetes and hosts, LLM observability, and distributed tracing with flamegraphs and waterfalls.
- What you give up
- You operate the whole data plane, which means ClickHouse is your problem, and our analysis of SigNoz says to skip it if you need a managed backend from day one because the free option is the self-hosted community build. There is a version coupling to check too: the analysis points at the collector version pinned in go.mod and asks you to confirm it matches what your applications already send. And the AI features are not all in the community edition, since the README says Noz is available only on SigNoz Cloud.
grafana/grafanaThe open and composable observability and data visualization platform. Visualize metrics, logs, and traces from multiple sources like Prometheus, Loki, Elasticsearch, InfluxDB, Postgres and many more.
- Best for
- Your metrics, logs and traces already sit in queryable stores and what is missing is a shared view: dashboards with template variables, Explore for ad-hoc queries and drilldown, switching from metrics to logs with preserved label filters, and alert rules with notifications to systems like Slack, PagerDuty, VictorOps and OpsGenie.
- What you give up
- It ships no database, no collector and no hosted service, so it is the wrong answer if that is what you were looking for. Our analysis of Grafana also makes the licensing point for companies: it is AGPL-3.0-only with Apache-2.0 exceptions listed in LICENSING.md, and that file is the first thing to read if you plan to embed it in a product. Before committing, confirm a data source plugin exists for your store and that your Grafana version matches the plugin API your plugins were built against.
openobserve/openobserveOpen source observability platform for logs, metrics, traces, frontend monitoring, pipelines and LLM observability. A sophisticated, simple and highly performant alternative to Datadog, Splunk, and Elasticsearch with 140x lower storage costs and single binary deployment.
- Best for
- You want one binary or container that ingests OpenTelemetry data and keeps Parquet files in object storage instead of running a search cluster, with logs, metrics, traces, Real User Monitoring and AI observability behind one UI. The README also describes a service graph, dashboards with template variables and geo maps, and SQL for logs and traces alongside PromQL for metrics.
- What you give up
- The repository's most recent tag is a release candidate, v1.0.0-rc1, so the stable line and the 1.0 line are not the same thing. Our analysis of OpenObserve also warns against evaluating it only in local mode: the object storage credentials have to work through ZO_S3_BUCKET_NAME and the related S3 variables, not just ZO_LOCAL_MODE, and the retention window has to fit the storage budget you actually have. AGPL-3.0 applies if you distribute a modified version.
- First install step
- Full setup guide
docker run -d \ --name openobserve \ -v $PWD/data:/data \ -p 5080:5080 \ -e ZO_ROOT_USER_EMAIL="[email protected]" \ -e ZO_ROOT_USER_PASSWORD="Complexpass#123" \ public.ecr.aws/zinclabs/openobserve:latest
uptrace/uptraceOpen source APM: OpenTelemetry traces, metrics, and logs
- Best for
- You already emit OTLP and want traces, metrics and logs in one self-hosted UI backed by ClickHouse, with users and projects managed through YAML config and single sign-on through OpenID Connect with providers such as Keycloak, Google Cloud and Cloudflare. The README also describes Grafana compatibility, so Grafana can use Uptrace as a Tempo or Prometheus datasource.
- What you give up
- The current release line is v2.1.0-beta, so there is no stable tagged release to pin, and our analysis of Uptrace says to skip it if that is a requirement and to verify that the beta you pick handles your span volume. The last push was 2026-08-13, which is the date to judge the pace by. It also needs two databases rather than one, ClickHouse for the telemetry and PostgreSQL for metadata such as metric names and alerts.
- First install step
- Full setup guide
uptrace: CGO_ENABLED=0 go build -trimpath -o ./bin/uptrace_$(GOOS)_$(GOARCH)$(EXTENSION) \ $(BUILD_INFO) -tags $(GO_BUILD_TAGS) ./cmd/uptrace uptrace-vue: pnpm --dir=vue install (cd vue && pnpm vue-cli-service build --mode=production) uptrace-all-sys: uptrace-darwin_amd64 uptrace-darwin_arm64 uptrace-linux_amd64 uptrace-linux_arm64 uptrace-windows_amd64 docker-uptrace: docker buildx build --file cmd/uptrace/Dockerfile \ --push --platform linux/arm64,linux/amd64 \ --tag uptrace/$(DOCKER_IMAGE):$(DOCKER_TAG) \ --tag uptrace/$(DOCKER_IMAGE):latest .
One query surface, one visualization layer, one Parquet object store, one ClickHouse
Datadog is a hosted observability platform: metrics, logs, traces, dashboards and alerts collected by an agent and OpenTelemetry. People look elsewhere for three reasons. Billing by hosts, ingested logs and custom metrics, which is hard to forecast. Telemetry leaves your network. And the agent and dashboard formats are proprietary, so the thing that reads your production data is a file only one product understands.
The four projects here divide along a line that is more useful than a feature comparison: who stores the data.
SigNoz/signoz and uptrace/uptrace both store telemetry in ClickHouse, and both put logs, metrics and traces behind one query surface. SigNoz describes itself as an open-source observability platform built on OpenTelemetry with logs, metrics, traces, alerts and dashboards in one place, and it stores everything in a single columnar database. Its run options are three: the community edition you deploy yourself with Docker, Kubernetes or Linux, an enterprise self-hosted or cloud offering with compliance, retention and data residency controls, and a managed cloud service. Uptrace is narrower: the README describes it as an open source APM using OpenTelemetry to collect and ClickHouse to store, with PostgreSQL alongside it for metadata such as metric names and alerts, a query builder, dashboards, alerting rules, notifications by email, Slack, webhook and AlertManager, and Grafana compatibility.
openobserve/openobserve takes a different storage decision. It is a single Rust binary that writes Parquet to object storage rather than maintaining a search cluster, with an S3-native design, and the README lists logs with full-text search and a visual query builder, distributed tracing with waterfalls, flame graphs and Gantt charts, a service graph, metrics queried with SQL or PromQL, dashboards, Real User Monitoring with Core Web Vitals and session replay, alerts, pipelines and AI observability.
grafana/grafana is the odd one out because it stores nothing. It is a visualization and alerting front end for data that already lives somewhere else, with the repository description naming Prometheus, Loki, Elasticsearch, InfluxDB and Postgres among the sources, and the README describing visualizations, dynamic dashboards with template variables, Explore for ad-hoc queries and drilldown, switching between metrics and logs with preserved label filters, alerting, and mixing data sources per query within a single graph.
Left out, and worth saying why: the search clusters themselves, which are storage engines rather than observability products, and the managed-only vendors of open source collectors. Both matter, and neither is a replacement for the query surface you are trying to choose.
Why New Relic is not on this list
New Relic is the other name that appears next to Datadog in most of these searches, and it is not here for the same reason: it is a hosted product, so your telemetry leaves your network and the bill follows your volume rather than your headcount.
That is not a quality judgement. New Relic has been a full observability platform for a long time, it covers applications and infrastructure in one place, and for a team that has already instrumented with its agents it is a working setup with institutional knowledge attached to it. None of that is in question.
The reason it does not qualify is the combination of the second and third reasons on the list. Once telemetry has to stay inside a network, or a forecast has to be bounded, the question stops being which product has more dashboards and becomes which storage engine you are willing to run. That is a genuine trade and not automatically a better one: a hosted platform that a team already knows how to operate can be the right answer for a long time.
Also absent, and worth naming: the commercial open-core products that sit between the two, offering a self-hosted edition with a paid tier above it. Several exist, and they are a reasonable middle path for a team that wants the data local but not the operations.
And a final absence that is easy to miss. None of these four replaces a managed service contract. Self-hosting means someone is on call for the storage engine, the ingestion path and the upgrade, and that is a role rather than a line item.
Choosing by scenario: a solo engineer, a small team, a company with residency rules, a developer integrating telemetry
The first question is whether you have data already or need a place to put it, because that splits the four cleanly.
A solo engineer who already runs Prometheus and Loki should look at grafana/grafana. It is the smallest addition to an existing setup: no database, no collector, just a place to query what is already stored, build dashboards and define alert rules. The cost of that approach is that everything else in the observability stack is still yours, which is fine if you already have it and not fine if you do not.
A small team that wants one place for everything should look at SigNoz/signoz. The README describes the feature set a modern team expects from a single pane: APM with latency, error rate, throughput and Apdex, log management that correlates with traces and metrics through a visual query builder, metrics via Query Builder, PromQL or ClickHouse SQL, Kubernetes and host infrastructure monitoring, distributed tracing with flamegraphs and waterfalls, and trace funnels for request-flow drop-offs. The cost is ClickHouse and the data plane around it.
A team that cares about storage cost above everything else should look at openobserve/openobserve, whose whole design is Parquet on object storage instead of a search cluster. It also ships Real User Monitoring with session replay, which the other three treat differently. The trade is a smaller integration ecosystem, which our analysis of OpenObserve names as the cost.
A company with residency or data-transfer requirements finds all four acceptable on the data question and different on the licence and operations questions. A developer integrating telemetry into a product is the case that needs care: Grafana can sit in front of Uptrace as a Tempo or Prometheus datasource, and Grafana's own licensing has an exceptions file that our analysis tells you to read first if you intend to embed it.
What each one asks you to run
The install commands on this page span from a package manager invocation to a single container with a data volume, and that range is the operational story.
openobserve/openobserve shows the most complete one: a docker run that mounts a local directory at /data, publishes port 5080, and sets the root user email and password as environment variables. Underneath is a single Rust binary, and the README points to a high availability deployment guide for clustered setups. So the minimum is one container and one volume, and the question is what that volume costs you in object storage over a retention window.
grafana/grafana shows yarn install --immutable, which is a monorepo source build rather than a deployment. That is the honest signal: what you run is a released package or container, and the repository is the front end, not a service you start from this command.
SigNoz/signoz and uptrace/uptrace have no install command in our analysis, and in both cases the reason is that what you deploy is a storage engine plus an application. SigNoz stores in a single columnar database, which our analysis identifies as ClickHouse, and it also ships a collector whose version the analysis asks you to check against what your applications already send. Uptrace needs two databases, ClickHouse for the telemetry and PostgreSQL for metadata, and its release line is a beta.
The pattern is worth stating plainly. Three of the four are a database with a query UI on top, and the fourth is a query UI with no database of its own. Deciding which one you want is deciding how much of the storage layer you are taking on.
Licences: AGPL-3.0 in three places, and one repository GitHub cannot classify
Three of these four are AGPL-3.0, which for an observability tool has a specific implication, and the fourth needs a file opened rather than a sentence written.
grafana/grafana is AGPL-3.0-only, and the README points to a LICENSING.md file for Apache-2.0 exceptions. That file matters more than usual here, because our analysis of Grafana singles it out: if you plan to embed Grafana in a product you ship, the licence plus its exceptions are the first thing to read. Grafana is also the one most commonly used as a component rather than a product, which is exactly the situation the exceptions file addresses.
openobserve/openobserve and uptrace/uptrace are AGPL-3.0. For a team running either without modification, the network clause does not change anything. For a team that modifies an alerting rule engine or adds an ingestion path and exposes the result to users, the source obligation applies, and our analysis of OpenObserve names the licence terms for a modified distribution as a condition to accept.
SigNoz/signoz is the one GitHub cannot classify from its repository metadata, so the terms have to come from the LICENSE file. Our analysis of SigNoz does not raise the question, which is another way of saying it is worth checking yourself before a legal review depends on it.
One point applies to all four. An AGPL licence governs the software you run, not the telemetry it stores. Whether your traces and logs can cross a network boundary, and for how long they are kept, is a decision none of these licences makes for you, and for most teams moving off a hosted platform that is the decision that actually matters.
Bottom line
Pick grafana/grafana when the data is already in Prometheus, Loki or Elasticsearch and the missing piece is a shared view, SigNoz/signoz when you want logs, metrics and traces in one query surface you control, openobserve/openobserve when storage cost and Real User Monitoring lead the decision, and uptrace/uptrace when you already emit OTLP and want ClickHouse with Grafana compatibility on top. Before committing, confirm a data source plugin or ingestion path exists for what you run today, read Grafana's LICENSING.md if you intend to embed it, and check that the SigNoz collector version matches your instrumentation.