SigNoz
Open-source APM and observability platform
SigNoz is an open-source application performance monitoring and observability platform built on OpenTelemetry. It unifies metrics, traces, and logs in a single self-hosted tool.
Key features
- OpenTelemetry native
- Unified metrics, traces, logs
- Application performance monitoring
- Custom dashboards and alerts
Pros & cons
Strengths
- Metrics traces logs unified
- OpenTelemetry native
- Flexible query dashboards
Trade-offs
- ClickHouse dependency heavy
- Resource-hungry stack
SigNoz replaces
Last reviewed Aug 26, 2026 · 793 words
The decision you are really making with SigNoz is not "SigNoz or Datadog". It is "one integrated observability app on ClickHouse, or four Grafana-family services stitched together". SigNoz gives you traces, metrics and logs in a single UI with a single query layer, installed from one compose file, at the cost of a 4 GB RAM floor and a ClickHouse instance you now own. The Grafana route gives you Grafana, Prometheus, Loki and Tempo, each lighter alone, each configured separately, and correlated only as well as you wire them. For a team of 2 to 20 engineers who want application traces without becoming a platform team, SigNoz is the faster path. For a homelab that only wants host metrics, it is 3 GB of RAM too many.
OpenTelemetry-native is the feature, not a buzzword
Every other tool in this space bolts OpenTelemetry on. SigNoz was built in 2021 assuming it, which shows in practical ways: the bundled OpenTelemetry Collector is the only ingestion path, so anything that can emit OTLP works with no SigNoz-specific agent. Your app sends to port 4317 (gRPC) or 4318 (HTTP), and the UI is on port 3301. Instrumenting a Python or Node service is the standard OpenTelemetry SDK plus two environment variables:
OTEL_EXPORTER_OTLP_ENDPOINT=http://signoz-host:4318
OTEL_SERVICE_NAME=checkout-api
Because there is no proprietary agent, switching away later costs nothing; the same instrumentation would feed Tempo, Jaeger or a paid vendor. That is a real reason to prefer it over the Datadog agent even before price enters the discussion. The Datadog alternatives page covers the wider field.
ClickHouse is where the 4 GB goes
The catalogue's "resource-hungry stack" warning is about ClickHouse, the columnar database SigNoz stores everything in. ClickHouse is spectacular at the queries observability needs (scan 50 million spans, group by service, p99 by minute) and it earns that speed with memory. On a 4 GB box, the default compose runs but leaves nothing for the workloads you are observing, so put SigNoz on its own VM or a dedicated 8 GB slice. Disk grows with ingestion; a modest 5-service setup writing 100 spans a second will fill about 1 GB a day before compression settles, and ClickHouse compresses well, so budget 30 GB and watch the first month.
Retention is set in the UI per signal (traces, metrics, logs) and defaults to 15 days for traces and logs. Set it before you forget; ClickHouse does not fill the disk gracefully.
Against the Grafana stack, honestly
| SigNoz | Grafana + Prometheus + Loki + Tempo | |
|---|---|---|
| Services to run | 4 (UI, query, collector, ClickHouse) | 4 to 5, each separately configured |
| Trace-to-log correlation | Built in, click through | Works, needs derived fields config |
| Metrics query language | PromQL and ClickHouse SQL | PromQL, LogQL, TraceQL |
| Host and container metrics | Via OTel collector receivers | Prometheus exporters, larger ecosystem |
| Dashboards community | Small | Enormous |
| RAM floor | 4 GB | 1 to 2 GB for metrics only, 4 GB with all four |
The Grafana stack wins on the size of its ecosystem and on partial adoption: you can run Prometheus alone for a year and add Loki later. SigNoz wins the moment you actually want traces, because the integrated experience is the product and the Grafana equivalent is four products that behave like four products. The Grafana vs Prometheus comparison on this site explains that split if the names are still blurring together.
The work is instrumentation, not installation
Installing SigNoz is a git clone and docker compose up from the deploy/docker directory; 20 minutes. The months are spent getting your services to emit useful spans: naming them, adding attributes, propagating context across queues and HTTP calls. SigNoz cannot fix a service that emits one span per request with no attributes. Auto-instrumentation gets Python, Java and Node about 70% of the way; the last 30% is a developer adding span.set_attribute("order.id", ...) in the right places. If your team will not do that, you will get a pretty dashboard with shallow data, and Prometheus plus Uptime Kuma would have served you the same.
What I'd do
For a small product team running 3 or more services in production, I'd run SigNoz on a dedicated 8 GB VM, set trace retention to 7 days and metrics to 30, instrument one service end-to-end before touching the others, and give it a quarter before judging. For a homelab, I would not run it; the homelab monitoring guide covers the lighter stack that fits in 512 MB. SigNoz is the best self-hosted answer to "I want what Datadog does" that exists in 2026, and it is only worth its RAM when that is the actual question.
Compare SigNoz
1 head-to-head comparisons.
Similar developer tools & git apps
Excalidraw
Developer Tools & GitVirtual hand-drawn style whiteboard
Replaces Miro
lazygit
Developer Tools & GitSimple terminal UI for Git commands
Replaces GitKraken, Sourcetree
Hoppscotch
Developer Tools & GitOpen-source API development ecosystem
Replaces Postman, Insomnia
json-server
Developer Tools & GitFull fake REST API from a JSON file in seconds
Replaces Mockoon, Postman Mock
Strapi
Developer Tools & GitLeading open-source headless CMS
Replaces Contentful
NocoDB
Developer Tools & GitOpen-source Airtable alternative
Replaces Airtable