SigNoz vs Grafana vs OpenObserve: what you actually run (2026)

Quick answer (2026)

If you want one process, one artefact and no second opinion about what you are allowed to run, deploy OpenObserve. It is stock AGPLv3 across everything published, it ships as a single Rust binary, and at 136.3 MB compressed it is smaller than any individual component of the other two stacks. The catch is that its commercial code is not in the repository at all, so "read the source" stops at the boundary.

If you already run Prometheus, already have dashboards people trust, and want storage you can scale one signal at a time, keep Grafana and add Loki, Mimir and Tempo underneath it. Grafana is not a competitor to the other two here, it is a query and visualisation layer, and treating it as a like-for-like alternative is the single most common error in this comparison.

Choose SigNoz if you want traces, metrics and logs correlated in one product out of the box and you are comfortable operating ClickHouse. Its core is MIT, which is the most permissive licence of the three, and that surprised us. What did not surprise us, once measured, is that its single-node stack is the heaviest of the three at 623.2 MB across four images.

Everything above was measured from licence files, source trees and the Docker Hub registry API on September 8, 2026. The figures and the file paths are in the tables below so you can re-run them.

What this comparison is not about

ShipGarden has shelved two adjacent categories and readers land on all three looking for different things, so the boundary is worth drawing before any numbers.

This is not about error monitoring with Sentry, GlitchTip and Highlight. Those catch a stack trace when something throws, attach it to a release, and page a human. The three tools here ingest continuous telemetry whether or not anything is wrong. Plenty of teams run one of each and are right to.

It is also not about LLM observability with Langfuse, LangSmith and Helicone. Those trace prompts, token spend and eval scores. The unit of interest there is a generation, not a span, and the retention economics are completely different.

What is left is the boring, load-bearing layer: where your spans, your counters and your log lines actually live, and who is allowed to run the code that stores them.

The comparison is not three of the same thing

The most useful fact about this trio is structural, and it is why "SigNoz vs Grafana" is a slightly malformed question.

SigNoz and OpenObserve are backends. They ingest OpenTelemetry data, store it, and render it. One deployment, one product.

Grafana is not a backend. It stores nothing. In a self-hosted comparison, "Grafana" is shorthand for the stack underneath it, conventionally Loki for logs, Mimir for metrics and Tempo for traces. That is four moving parts before you have ingested a byte.

This matters for a practical reason rather than a pedantic one. If you already have Prometheus scraping, you have most of a Grafana stack already and adding Loki is an increment. If you have nothing, you are choosing between assembling four components and installing one product. The rest of this comparison only makes sense once that asymmetry is on the table.

The licence inversion, read on September 8, 2026

We read all three licence files directly rather than trusting a badge. The result runs opposite to the reputations.

Grafana's and OpenObserve's licence files are the same length because both are the unmodified AGPLv3 text with no carve-out of any kind.

SigNoz's is a 24-line splitter. Its operative sentence is that everything under ee/ and cmd/enterprise/ falls under a separate ee/LICENSE, third-party components keep their own licences, and "Content outside of the above mentioned directories or restrictions above is available under the 'MIT Expat' license".

So the project with a visible commercial directory has the more permissive core. MIT lets you fork SigNoz's core, embed it in a product and sell it. AGPL does not, without reciprocity.

The milder reading, which is the accurate one. If you are self-hosting an observability backend for your own application, this difference is close to irrelevant. AGPL's obligations bite when you convey the software or offer a modified version to remote users as a service. Running Grafana for your own engineers triggers essentially nothing you would notice. The licence gap becomes real in exactly one situation: you want to build a product on top and ship it to customers. If that is not your plan, do not let the licence column decide this.

The narrower restriction is the one worth reading closely. ee/LICENSE (2,167 B) says the enterprise code "may only be used in production, if you (and any entity that you represent) have agreed to, and are in compliance with, the SigNoz Subscription Terms of Service" and hold "a valid SigNoz Enterprise license for the correct number of user seats". It explicitly permits copying and modifying for development and testing without a subscription. It is a production restriction, not a look-but-do-not-touch restriction.

The visibility inversion: what a 781-byte file tells you

Here is where the three genuinely diverge, and it is not visible from a licence badge.

SigNoz puts its commercial code in the repository you clone. ee/ holds fifteen real directories: anomaly, auditor, authn, authz, gateway, licensing, metercollector, meterreporter, modules, querier, query-service, sqlschema, sqlstore, subscription and zeus. You can read all of it.

OpenObserve appears to do the same and does not. Its tree has src/enterprise/, which looks like open-core in the open. Opening it returns four subdirectories, each containing exactly two small files. o2_enterprise/lib.rs is 781 bytes, and after the AGPL header its entire content is one line:

//! Cargo dependency-resolution stub for the private `o2_enterprise` crate.

o2_dex/lib.rs (774 bytes) says the same thing about o2_dex. These are placeholders that exist so cargo can resolve the dependency graph when building the open edition; the root Cargo.toml carries an enterprise feature that switches nine sub-crates over when the real, private crates are substituted. The four candidate repositories all return HTTP 404 to an unauthenticated request.

This is why OpenObserve's stock AGPL licence file with no carve-out is accurate rather than sloppy: everything actually present in the repository really is AGPL. The enterprise code is not licensed differently, it is absent.

Grafana does the same thing with a different accent. pkg/extensions/ contains .keep, main.go, enterprise_imports.go and its test. The enterprise build links against code held elsewhere, and github.com/grafana/enterprise returns 404 unauthenticated.

So the inversion is this: the two AGPL projects, which look maximally open, keep their commercial code somewhere you cannot read it. The MIT-cored project shows you every line and tells you which ones you may not run in production. Reasonable people prefer different sides of that trade, but it is the opposite of what the licence badges imply.

Where SigNoz's line actually falls, and the part that will catch people

Fourteen of the fifteen ee/ directories have an identically named twin under pkg/. Only ee/anomaly has no counterpart. That is not duplication, it is the shape of the product: one interface, two implementations, one on each side of the licence line.

The clearest example is licensing itself. pkg/licensing/nooplicensing/provider.go is the MIT no-op. ee/licensing/httplicensing/provider.go (7,836 B) is the one that calls home.

The example that will actually affect a deployment is the metadata store.

pkg/sqlstore/ contains exactly one backend, sqlitesqlstore. The Postgres implementation, postgressqlstore, is in ee/. And the registration point is unambiguous. In pkg/signoz/provider.go:

func NewSQLStoreProviderFactories() factory.NamedMap[...] {
	return factory.MustNewNamedMap(
		sqlitesqlstore.NewFactory(...),
	)
}

One provider. The two binaries then differ by almost nothing. cmd/community/metastore.go is 550 bytes and returns that map unchanged. cmd/enterprise/metastore.go is 1,073 bytes and returns the same map with one addition:

existingFactories := signoz.NewSQLStoreProviderFactories()
if err := existingFactories.Add(postgressqlstore.NewFactory(...)); err != nil {
	panic(err)
}

The trap is in the config surface. pkg/sqlstore/config.go is MIT, and it defines a full PostgresConfig struct with a DSN field, plus a Postgres field on the main Config. The open build will happily parse provider: postgres out of your configuration file and then find nothing registered to satisfy it. The configuration surface and the capability are on opposite sides of the line.

Practically: the open build of SigNoz stores its metadata in SQLite, at /var/lib/signoz/signoz.db in WAL mode by default. Be precise about what that means. Your telemetry still goes to ClickHouse in both editions; the SQLite file holds dashboards, alert definitions, users and saved views. For a single node that is completely fine and arguably the right call. It becomes a constraint the moment you want more than one replica of the query service in front of shared state.

What each one actually costs you to run

Every figure below is the compressed amd64/linux size reported by the Docker Hub registry API on September 8, 2026, taken from the newest stable semver tag rather than a nightly or release candidate, because mixing those makes the comparison meaningless.

Scroll to see more

Stack	Images	Components
OpenObserve	136.3 MB	1: openobserve v0.92.2
Grafana + LGTM	450.6 MB	4: grafana 13.0.8 (336.9), loki 3.6.16 (41.3), mimir 3.1.5 (35.2), tempo 3.0.3 (37.2)
SigNoz single-node	623.2 MB	4: signoz v0.140.0 (72.9), otel-collector v0.144.9 (184.2), clickhouse 26.3.32 (254.2), zookeeper 3.9.5 (111.9)

This inverts the usual pitch. SigNoz is marketed as the uncomplicated alternative to assembling a Grafana stack, and on this measure it is the heavier of the two: the same number of containers and 38% more bytes. OpenObserve is 4.6x lighter than SigNoz and 3.3x lighter than the Grafana stack, on one image instead of four.

Two honest qualifications, because a size table is easy to over-read.

Compressed image size measures deployment weight, not runtime cost. It tells you what you pull, store in a registry and ship to an air-gapped site. It does not tell you how much RAM ClickHouse will want under load. Nobody should pick an observability backend on megabytes alone.

The distribution is more informative than the total. Grafana's own image is 336.9 MB, the largest single artefact anywhere in the table, and it stores nothing at all: that is UI, plugins and a bundled frontend. Loki, Mimir and Tempo together come to just 113.7 MB because they are Go binaries that push their data to object storage. ClickHouse alone is 254.2 MB, more than twice those three combined, because it is a complete analytical database. Read the table as a map of where each project put its complexity, not as a league table.

The finding that mildens the SigNoz picture

Since ee/ is in the tree, the obvious next question is whether the published image contains code you are not licensed to run. We checked, and the answer is better than we expected.

SigNoz publishes two images, in lockstep, at identical version numbers on identical dates:

Two things follow. First, the entire commercial edition is about 1.8 MB compressed, roughly 2.5% of the image, and the delta is stable across four consecutive releases rather than being measurement noise. Second, and more usefully, a provably community-only image exists and is maintained on the same release train. If your legal team would rather not have restricted code sitting on disk, signoz/signoz-community is a real answer rather than a build-it-yourself project.

The caveat is defaults. The image everyone reaches for, and that the documentation names, is signoz/signoz, which is the enterprise-capable build. signoz/signoz-enterprise does not exist. You get the licence-gated binary unless you know to ask for the other one.

SigNoz has retired Docker Compose, and that is recent

This is the finding least likely to appear in an older comparison, and it changes the self-hosting answer outright.

SigNoz has deprecated install.sh and the bundled Compose and Swarm manifests. deploy/install.sh is now a 728-byte stub whose only job is to print a pointer elsewhere. Installation goes through a vendor CLI called Foundry, installed with a piped shell script, which generates manifests from a casting.yaml via foundryctl forge and applies them with foundryctl cast.

The migration guide is candid about the consequence, and it is worth quoting exactly:

From SigNoz's own migration guide: "Keep a copy of your existing docker-compose.yaml / stack file (and any config it references). SigNoz no longer distributes these files, so this copy is your only way to roll back."

Weigh this how you like. A single declarative file and one CLI is a genuinely nicer happy path than a sprawling Compose file, and the guide is careful about preserving volumes. But you are trading a portable, universally understood artefact for a vendor-specific tool, and you can no longer read a Compose file to find out what will run on your host. For teams with an existing deployment pipeline built around Compose or Swarm manifests, this is real migration work rather than a version bump.

For the record, the casting.yaml in that guide reproduces the legacy single-node topology as metastore: sqlite, telemetrykeeper: zookeeper, telemetrystore: clickhouse, which is the same four-service shape as the size table above.

Release cadence, measured

Pulled from the GitHub releases API on September 8, 2026, most recent five releases each.

• SigNoz ships a single line at roughly weekly intervals: v0.140.0 (Sep 2), v0.139.0 (Aug 26), v0.138.0 (Aug 19), v0.137.1 (Aug 14). Gaps of 7, 7, 4 and 2 days.
• OpenObserve is mid-way to a 1.0: v1.0.0-rc3 (Sep 8), rc2 (Sep 3), rc1 (Aug 28), with v0.92.2 (Aug 17) the newest stable. If you deploy it today you are deploying a 0.x release while a 1.0 is in candidate.
• Grafana published four versions on the same day, September 2, 2026: v13.2.1, v13.1.5, v13.0.8 and v12.4.10. That is maintained release branches with backported fixes, which is a different and considerably more conservative posture than a single moving line. If you need to stay on a minor version for a year and still receive patches, only one of these three is currently set up for it.

Where each one loses

SigNoz loses on operational surface. You are running ClickHouse and ZooKeeper whether or not you wanted a distributed analytical database, and the open build pins you to SQLite for metadata. The Compose retirement means your install path now depends on a vendor CLI. The heaviest stack of the three, on the measure above.

Grafana loses on assembly. Four components, each with its own configuration, storage layout and upgrade cycle, and correlation between traces and logs is something you configure rather than something you get. Its own image is the largest single artefact in this comparison. It is also the only one of the three where "install it" is not a meaningful instruction.

OpenObserve loses on transparency and maturity. The enterprise code is genuinely unavailable, so you cannot audit what a paid feature does or fork around it, and the four stub crates are a polite way of telling you where the wall is. Its newest stable tag is 0.92.2, and its README's claim of "140x lower storage cost" is the vendor's own marketing figure, not something we measured or would repeat without a benchmark behind it.

What we did not measure

Stating this plainly matters more than the parts we did measure.

We did not run ingest benchmarks, so nothing here speaks to query latency, cardinality limits or cost per ingested gigabyte at any volume. We did not measure RAM or CPU under load, which is the number that will actually decide your bill. We did not evaluate alerting, dashboard quality or the OpenTelemetry Collector configuration surface. We did not test any of the paid tiers. And we did not verify OpenObserve's high-availability topology beyond reading its documentation, so the single-binary claim is confirmed for single-node only.

We also read source trees rather than the compiled binaries. A directory listing tells you where the code lives, not with certainty what shipped in a particular image.

If you are choosing today

Run OpenObserve if operational simplicity dominates and you can accept a 0.x stable and a closed commercial edition. It is one binary, it is the lightest by a wide margin, and everything published is AGPL with no small print.

Run SigNoz if you want correlated traces, metrics and logs as a product decision rather than an integration project, you are already comfortable with ClickHouse, and single-node metadata is acceptable. Pull signoz/signoz-community deliberately if you want the MIT-only build, and budget time for the Foundry migration if you are coming from Compose.

Run Grafana with Loki, Mimir and Tempo if you already have Prometheus, if dashboards are the artefact your team actually values, or if maintained release branches matter to your upgrade policy. It is the most assembly and the most control.

The one recommendation that survives any of these projects changing its pricing tomorrow: decide first whether you are willing to operate a database. SigNoz means ClickHouse plus ZooKeeper. Grafana means object storage plus three services. OpenObserve means a binary and a disk or an S3 bucket. That question settles this comparison far more reliably than any feature table, and it is the one that does not move.

Sources we read directly

All fetched September 8, 2026.

• SigNoz root LICENSE and the ee/ split, 1,589 bytes, the MIT Expat grant and the two excluded directories.
• SigNoz migration guide to Foundry, 8,808 bytes, including the rollback warning quoted above.
• OpenObserve's enterprise stub crate, 781 bytes, which describes itself.
• Grafana's LICENSE, 34,523 bytes of unmodified AGPLv3.

Image sizes came from the Docker Hub registry API, amd64/linux, newest stable semver tag per repository. Release dates came from the GitHub releases API.