SigNoz ships two binaries from one tree, and its AI investigator is Cloud only

The Makefile builds a community and an enterprise binary from two context directories

The free build and the commercial one are not the same binary with a flag. The build file points at two separate context directories, cmd/community and cmd/enterprise, and stamps a variant of community into the community build through the version flags. The targets follow the same split, with go build prefixes for community and for enterprise across amd64 and arm64, plus a separate enterprise race build. The repository root carries an ee directory next to pkg, and the module file requires Go 1.25.7.

Three run modes, and the compliance list belongs to the paid ones

The overview splits into three ways to run it. Cloud is the recommended one: fully managed, a 30 day free trial with no credit card, usage based pricing starting at $49, and regional data hosting. Enterprise covers Enterprise Cloud, bring your own cloud, or Enterprise Self-Hosted, and it is the tier that carries compliance, support, custom retention, RBAC, ingestion controls, data residency and region selection. Community is the free open source build that runs in your own infrastructure, deployed with Docker, Kubernetes or Linux, keeping full control of the data plane. RBAC, ingestion controls and custom retention are listed under the enterprise tier, so check whether the community build covers them before assuming self hosting does.

Noz, the in-product investigator, is available only on SigNoz Cloud

The agent native part of the product splits in two. There is a SigNoz MCP server, whose stated purpose is to bring telemetry into coding agents, and there is Noz, which runs inside SigNoz to investigate incidents, tune alerts and build dashboards with production context. The overview says Noz is available only on SigNoz Cloud. The consequence is specific: a self hosted install collects, queries and alerts on your telemetry, and the agent that reads that telemetry for you is not part of it. So the most attractive feature in the AI story is also the one that pushes a team toward the hosted plan.

The pricing claims are about billing shape, not about volume

Two separate claims sit near each other and are easy to merge. The pricing claim is a list of what is not charged: no per host pricing, no user seat pricing, and no special pricing for custom metrics. The cost claim is that cloud pricing is usage based and starts at $49. Neither statement puts a number on ingest volume, retention length or cardinality, which are the three things that decide a bill. Custom retention appears in the enterprise list, alongside RBAC and ingestion controls. The practical consequence is that you can rule out seat and host line items when you build a business case, and you still have to ask what a gigabyte or a month of retention costs before you can compare it with the stack you already run.

The Elastic number comes from the vendor's own ingestion study

The comparison section opens with three familiar tools, and the reasoning is scope based in two of the three cases. Prometheus is described as good if you just need metrics, with SigNoz keeping metrics, logs, traces, dashboards and alerts together. Jaeger is described as only doing distributed tracing, with SigNoz adding metrics, logs, trace analytics, dashboards, alerts, exceptions and trace to log workflows. The third is different: SigNoz is said to use a columnar database with a 50 percent lower resource requirement compared to Elastic during ingestion, and the number links to a study hosted on the project's own blog. So that figure is a vendor measurement of one phase, ingestion resources.

Metrics accept three query languages, and logs use a different one

The query surface is where the single database claim becomes visible. Dashboards for application, infrastructure and custom metrics can be built with Query Builder, with PromQL, or with ClickHouse SQL, which means a team arriving from Prometheus can keep its existing metric queries while a team that wants to shape data differently writes SQL against the storage engine. Log management is described separately, with a visual query builder for ingesting, searching, aggregating and correlating logs against traces and metrics. The single columnar database is what makes the cross signal work, and the module file shows a ClickHouse driver, a ClickHouse SQL parser, an in house expression evaluator and a cache, so the correlation story rests on one storage layer rather than a join across systems. The cost is that ClickHouse SQL is one of the supported dialects, so a dashboard can become engine specific.

Trace funnels answer a different question from flamegraphs

Distributed tracing is presented with the familiar surfaces: flamegraphs, waterfalls, span events, filters and trace analytics. Trace funnels are presented as a separate thing, created from traces to understand request flow drop offs, failed transitions and systemic workflow issues. That is a different unit of analysis. A flamegraph tells you where time went inside one request, and a funnel asks how many of the steps that make up a workflow were actually reached, which is the question you ask when an onboarding flow or a checkout path loses people. The dependency follows from where the data comes from: a funnel is computed over trace data, so it inherits whatever your collector and instrumentation decided to keep.

Licence metadata, four README translations, and a collector on its own line

Three details in the repository are worth a reader's time. First, the licence attached to the repository is recorded as no recognised assertion while a LICENSE file sits in the root, and the build file injects a licence endpoint address, so anyone planning to redistribute or vendor the code has to open that file rather than trust the badge. Second, the project keeps four readme files, English plus Simplified Chinese, German and Brazilian Portuguese, which are separate files that can lag the English one after a release. Third, the release line moves quickly: v0.147.0 on 2026-10-22, v0.148.0 on 2026-10-28 and v0.148.1 on 2026-10-29, with the last push dated 2026-11-02. The module file also pins a separate collector project at v0.144.6, a different version line from the application's latest release v0.148.1, so the telemetry pipeline you deploy is not the same number as the server you deploy.

Editorial conclusion

Pick the community build when your team wants correlated logs, metrics and traces on infrastructure it controls, and read the install guide for your platform before sizing the ClickHouse side. Do not expect the self hosted tier to include the parts of the product described as Cloud only, and treat the vendor's own comparison numbers as claims to verify against your own workload before you plan a migration.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. SigNoz/signoz on GitHub