SigNoz vs Grafana LGTM Stack

One Dashboard to Rule Them All, or Four That Almost Work Together

SigNoz wins for small teams starting from scratch, and the Grafana LGTM stack wins the moment you already have Prometheus and Grafana dashboards worth protecting.

You check your metrics dashboard: spike on CPU, got it. You pivot to logs, but that’s a different datasource, different login, different URL. You find a trace ID in the logs, but your tracing tool doesn’t know about it unless you manually cross-reference. By the time you’ve correlated everything, it’s 3 AM and you’ve rage-quit twice.

This is the observability problem. And there are two camps solving it right now: the Grafana LGTM stack (Loki + Grafana + Tempo + Mimir), four best-in-class tools that you wire together yourself, and SigNoz, one unified app backed by ClickHouse that handles all of it with a single OTLP endpoint and implicit correlation baked in.

I’ve run both. Let me tell you what nobody in the “just use Grafana Cloud” crowd admits out loud.

Full example: Clone the working files at github.com/KingPin/sumguy-examples/observability/signoz-vs-grafana-lgtm

What Is the LGTM Stack, Exactly?

LGTM stands for Loki, Grafana, Tempo, Mimir, four Grafana Labs projects that together cover the three observability pillars:

• Loki: log aggregation. Think Elasticsearch, but cheaper on disk because it only indexes labels, not full text. Queries via LogQL.
• Grafana: the dashboard and visualization layer. The one thing everyone already has.
• Tempo: distributed tracing. Stores spans, lets you do trace-to-log correlation via exemplars. Queries via TraceQL.
• Mimir: long-term Prometheus-compatible metrics storage. Horizontally scalable, handles billions of active series. PromQL queries.

The fourth letter G does double duty: Grafana is both the frontend for everything AND the “G” in the acronym. That’s not confusing at all.

Each of these is a legitimate, production-grade project. Loki is excellent. Tempo is solid. Mimir is what you graduate to when Prometheus runs out of runway. Grafana’s dashboarding is genuinely best-in-class for flexibility.

The catch: they’re four separate systems. Four separate containers (minimum). Four separate data stores. Four sets of configs, retention policies, and upgrade cycles. Four things that can drift out of sync with each other. If you want cross-signal correlation, like clicking a trace ID in Grafana and jumping directly to the correlated logs, you have to wire that up manually via datasource links and exemplar configs.

It works. It’s just… a lot of bolts.

What Is SigNoz?

SigNoz is an open-source observability platform that handles logs, metrics, and traces in a single app, backed by ClickHouse as the storage layer.

You get:

• One UI for everything
• One OTLP (OpenTelemetry Protocol) endpoint for ingestion
• Built-in trace-to-log-to-metric correlation, no manual linking required
• Dashboards, alerts, and a query builder without needing to know PromQL
• ClickHouse SQL available as an escape hatch for power queries

The architecture is: your app → OTEL Collector → SigNoz backend (query service + ClickHouse). That’s it.

SigNoz isn’t trying to be Grafana. It’s not going to win on dashboard customization or mixed-datasource flexibility. What it wins on is getting you from zero to correlated observability in an afternoon without reading four separate configuration manuals.

For more detail on how SigNoz compares to Uptrace (another ClickHouse-backed option), see SigNoz vs Uptrace.

The Setup Tax

Let’s be honest about what “assembling” the LGTM stack actually looks like. Here’s the minimum viable Compose for self-hosting:

# Minimal LGTM — and this is already a lot
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus

  mimir:
    image: grafana/mimir:latest
    command: ["-config.file=/etc/mimir/mimir.yaml"]
    volumes:
      - ./mimir.yaml:/etc/mimir/mimir.yaml
      - mimir_data:/data

  loki:
    image: grafana/loki:latest
    command: -config.file=/etc/loki/loki.yaml
    volumes:
      - ./loki.yaml:/etc/loki/loki.yaml
      - loki_data:/loki

  tempo:
    image: grafana/tempo:latest
    command: ["-config.file=/etc/tempo.yaml"]
    volumes:
      - ./tempo.yaml:/etc/tempo.yaml
      - tempo_data:/tmp/tempo

  grafana:
    image: grafana/grafana:latest
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=changeme
    volumes:
      - ./grafana/provisioning:/etc/grafana/provisioning
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"

volumes:
  prometheus_data:
  mimir_data:
  loki_data:
  tempo_data:
  grafana_data:

That’s five containers, and you still need: prometheus.yml, mimir.yaml, loki.yaml, tempo.yaml, and Grafana provisioning YAML files to wire the datasources together. You’re writing six config files before you’ve sent a single trace.

Now here’s SigNoz:

services:
  clickhouse:
    image: clickhouse/clickhouse-server:24.1.2-alpine
    environment:
      CLICKHOUSE_DB: signoz_traces
      CLICKHOUSE_USER: default
      CLICKHOUSE_DEFAULT_ACCESS_MANAGEMENT: 1
    volumes:
      - clickhouse_data:/var/lib/clickhouse
    ulimits:
      nofile:
        soft: 262144
        hard: 262144

  otel-collector:
    image: signoz/signoz-otel-collector:0.88.16
    command: ["--config=/etc/otel-collector-config.yaml"]
    volumes:
      - ./otel-collector-config.yaml:/etc/otel-collector-config.yaml
    ports:
      - "4317:4317"   # OTLP gRPC
      - "4318:4318"   # OTLP HTTP
    depends_on:
      - clickhouse

  signoz:
    image: signoz/frontend:0.49.0
    ports:
      - "3301:3301"
    depends_on:
      - clickhouse

  query-service:
    image: signoz/query-service:0.49.0
    environment:
      - ClickHouseUrl=tcp://clickhouse:9000/?database=signoz_traces
    depends_on:
      - clickhouse

volumes:
  clickhouse_data:

One config file. One OTLP endpoint. Four containers that actually belong together.

Wiring Your App to Either Stack

For LGTM, you’d need to send metrics to Prometheus (scrape endpoint), logs to Loki (push via Promtail/Alloy/OTEL), and traces to Tempo (OTLP). Three different destinations, potentially three different agent configs.

For SigNoz, everything goes to one place via OpenTelemetry:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 100ms

exporters:
  clickhouse:
    endpoint: tcp://clickhouse:9000/?database=signoz_traces
    logs_table_name: logs
    traces_table_name: signoz_index_v2
    metrics_table_name: signoz_metrics_v2

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [clickhouse]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [clickhouse]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [clickhouse]

Then from your app (Python example using the OTEL SDK):

pip install opentelemetry-sdk opentelemetry-exporter-otlp

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

provider = TracerProvider()
exporter = OTLPSpanExporter(endpoint="http://localhost:4317", insecure=True)
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)

One endpoint. Traces, logs, and metrics all funnel through the same collector. That’s it.

For more on the OTEL wiring side, see OpenTelemetry for Self-Hosters.

The Correlation Question

Here’s where the architecture difference really bites you with LGTM.

When you’ve got a slow request in Tempo traces, you want to jump to the correlated logs. Grafana can do this: you set up a “derived fields” config on your Loki datasource that detects trace IDs in log lines and turns them into clickable links back to Tempo. You also configure exemplars in Prometheus/Mimir to link metrics to traces.

It works. But you have to build it. Every piece of that correlation plumbing is a config block you write, test, and maintain. If your log format changes, you fix the regex. If you upgrade Tempo and the link format shifts, you update the derived field pattern.

In SigNoz, this is implicit. A trace ID is a trace ID. Click it anywhere in the UI and you get the correlated logs and metrics automatically. The correlation isn’t a config, it’s just how the system stores data in ClickHouse. One schema, one truth.

For a deeper dive on Tempo specifically, see Tempo + Grafana Distributed Tracing.

Feature Comparison

Resource Footprint Reality Check

Running the full LGTM stack on a homelab box is not trivial. Rough numbers with light traffic:

• Prometheus: ~300 MB RAM
• Mimir: ~500 MB to 1 GB RAM (it’s chunky)
• Loki: ~400 to 600 MB RAM
• Tempo: ~300 MB RAM
• Grafana: ~200 to 400 MB RAM

You’re looking at 2 to 3.5 GB RAM before you’ve ingested anything meaningful. Add your actual workload and retention and you’re at 4 to 5 GB for a comfortable setup. On a box with 8 GB shared with your actual services, that stings.

SigNoz + ClickHouse runs comfortably at 1.5 to 2 GB RAM for light workloads. ClickHouse’s columnar storage is obscenely efficient for time-series observability data, you’ll also get better query performance on heavy log searches than Loki because ClickHouse actually indexes the content.

If you’re on a tight resource budget, SigNoz wins this round without much debate. See ClickHouse for Self-Hosted Observability for why ClickHouse is such a good fit here.

Where LGTM Genuinely Wins

Let’s not pretend SigNoz is the universal answer, because it isn’t.

You already have Prometheus. If you’ve got three years of Prometheus data and a fleet of exporters, you’re not replacing that with SigNoz. LGTM lets you keep Prometheus and add Mimir for long-term storage. SigNoz is OTLP-native: you can point Prometheus remote-write at its OTEL collector (there’s a remote-write receiver), but its happy path is OpenTelemetry, and re-instrumenting everything to lean on it properly is a project, not an afternoon.

Dashboard flexibility. Grafana’s dashboard editor is the undisputed champion of “make this look exactly like I want.” Variables, repeat panels, transformations, conditional visibility, 100+ panel types, and a plugin ecosystem with years of community-built dashboards you can import immediately. SigNoz’s dashboard UI is solid for what it does but you’ll hit its ceiling faster.

Mixed datasources. Your metrics are in Mimir, your business data is in PostgreSQL, and you want to correlate them on a single Grafana dashboard? Easy. Grafana supports dozens of datasources natively. SigNoz is a closed system: everything has to go through ClickHouse.

Community and integrations. Grafana is embedded in basically every cloud provider’s monitoring story. There are Grafana dashboards for every piece of software you run. Stack Overflow answers, blog posts, Kubernetes operators, Helm charts, the ecosystem is enormous. SigNoz is growing but it’s nowhere near that density yet.

Where SigNoz Wins

You’re starting from scratch. No existing Prometheus, no existing dashboards, no legacy investment. SigNoz gets you operational faster by a significant margin. You don’t need to know four query languages, configure six datasource links, or read four separate docs sites.

Small team or homelab. Honestly, if you’re a one-to-five person team or a solo homelabber, the LGTM operational overhead is real. Someone has to own the upgrade cycle for four separate projects. Someone has to debug why Tempo can’t talk to Loki when you bump a minor version. SigNoz reduces that surface area dramatically.

Built-in correlation. The trace-to-log-to-metric jump in SigNoz is genuinely better out of the box than anything you’ll build manually in Grafana derived fields. When it’s 2 AM and a service is on fire, you want to click a trace ID and see the logs, not go find your datasource config and wonder if the regex is right.

Simpler alerting. SigNoz’s alerting is less powerful than Grafana Alerting, but it’s also faster to set up. Threshold alert on a metric? Two clicks. Create a correlation alert when error rate spikes? Built-in query builder handles it without writing PromQL from memory at midnight.

Decision Matrix: Pick Your Fighter

Pick SigNoz if:

• You’re starting fresh with no existing observability setup
• Your team is small (1 to 5 people) and observability isn’t a full-time job
• You want trace-to-log-to-metric correlation working today, not after a config sprint
• Your resource budget is tight (< 8 GB RAM on the monitoring host)
• You’re all-in on OpenTelemetry (you should be)
• You want one place to look at and one endpoint to send to

Pick LGTM if:

• You already have Prometheus and Grafana running: don’t rip them out
• Your team has Grafana expertise and existing dashboards to protect
• You need mixed datasources (databases, APM tools, cloud providers) in one view
• Dashboard customization matters more than setup simplicity
• You have dedicated infra resources and someone who owns the stack
• You want maximum flexibility on storage backends (S3, GCS, local)

The grey zone: If you’re running a serious homelab with 20+ services and you genuinely care about long-term metrics retention, it’s worth the LGTM complexity. But if you’re trying to get your three-service side project instrumented so you stop flying blind, SigNoz is the right call and you’ll be productive in an afternoon.

The SumGuy Take

The Grafana LGTM stack is like buying separate components for a home theater. Individually, the amplifier, the receiver, the subwoofer, and the projector are all top-tier. You’ll get phenomenal results if you have the time to read manuals, run the wiring, calibrate everything, and fix it when the HDMI handshake breaks on upgrade day.

SigNoz is the soundbar. It’s not as powerful at the top end. But it works the moment you plug it in, it sounds great for 90% of what you’re doing, and you didn’t spend the weekend in the manual.

For homelabbers and small teams: SigNoz is the pragmatic choice in 2026. The correlation story is genuinely better, the resource footprint is lower, and OTLP standardization means you’re not betting on a proprietary ingestion path anyway.

For teams with existing Grafana investment, dedicated infra, and people who know PromQL in their sleep: LGTM is still the king for flexibility. You’re not going to beat Grafana dashboards for customization, and if you’re already running Prometheus, adding Mimir and Tempo to an existing stack is cheaper than migrating everything to SigNoz.

Either way, the days of “throw it at Elasticsearch and hope” are over. ClickHouse-backed columnar storage for observability is fast, cheap, and scales better than you’d expect. SigNoz is proof that you don’t need a FAANG-scale stack to have FAANG-quality observability on a homelab budget.

Your 2 AM self will thank you for picking one and actually setting it up, instead of arguing about it on the internet until sunrise.

Related Reading

• Grafana Alloy: Replacing the Agent After Deprecation
• Promtail to Alloy Migration: A Practical Diff
• TIG: Telegraf + InfluxDB + Grafana
• Alertmanager Routing Trees That Don’t Lie
• Blackbox Exporter: HTTP/TCP/DNS/ICMP Probes