Grafana 13 and Loki 3.0: The LGTM Stack Just Got Production-Ready at Any Scale

GrafanaCON 2026: The LGTM Stack Hits Production Maturity
Grafana Labs launched Grafana 13 at GrafanaCON in April 2026, alongside major updates to every component of the LGTM stack - Loki 3.0 for logs, Tempo 2.8 for traces, Mimir 2.16 for metrics, and Grafana itself as the unified frontend. The message was unambiguous: the open-source LGTM stack is now a drop-in replacement for Datadog, New Relic, and Splunk at any scale.
Two stats from Grafana Labs' 2026 Observability Survey: 71% of organizations are using or migrating to OpenTelemetry, and self-hosted observability adoption grew 42% year-over-year as teams recoil from SaaS vendor bills that scale with ingestion volume.
Grafana 13: What Changed
OpenTelemetry-First Dashboards
Grafana 13 introduces native OpenTelemetry data source support - not a plugin, not a translation layer. OTLP metrics, traces, and logs arrive directly into Grafana without passing through Prometheus or Tempo first. This means:
- No format conversion: OTLP → storage directly, no intermediate scraping or relabeling
- Unified query language: Explore view works across metrics, traces, and logs with a single query bar
- Vendor-neutral instrumentation: Instrument once with OpenTelemetry SDKs. Point at Grafana Cloud, self-hosted LGTM, or any OTLP-compatible backend. No code changes.
Explore Metrics - Automatic Cardinality Analysis
High-cardinality metrics (thousands of label combinations) are the silent killer of Prometheus performance. Grafana 13's Explore Metrics view automatically identifies high-cardinality labels, shows cardinality distribution, and suggests label drops - before you run out of memory.
# Grafana 13 will flag this:
http_requests_total{user_id, session_id, trace_id, ip_address}
# And suggest this:
http_requests_total{method, status, endpoint}
Scenes-Powered Dashboards
Dashboard variables, repeated panels, and dynamic layouts are now built on Scenes - Grafana's new frontend architecture. No more "variable interpolation lag" on dashboards with 50+ panels. The entire dashboard re-renders in sub-100ms.
Alerting 2.0
Alert rules can now reference data from multiple sources in a single rule. For example: "Alert if error rate from Tempo exceeds 5% AND CPU from Prometheus exceeds 80%." Previously this required two separate alerts and manual correlation.
Adaptive Metrics (GA)
First introduced as experimental in Grafana 12, Adaptive Metrics is now GA. It automatically identifies unused or rarely-queried metrics and suggests aggregation rules that reduce cardinality without losing queryability. Early adopters reported 40-60% reduction in Prometheus TSDB size.
Loki 3.0: The Logging Engine Rebuilt
Loki 3.0 is the biggest architectural change since Loki 2.0's index-free ingestion model. Three major changes:
Bloom Filters for Query Acceleration
Loki 3.0 adds Bloom filter indexes - not full-text indexes (which blow up storage), but probabilistic filters that eliminate 95%+ of chunks before they touch disk. A query for {app="api"} |= "timeout" used to scan every chunk in the time range. Now Loki checks the Bloom filter, identifies the ~5% of chunks that might contain "timeout", and only reads those.
Result: query performance improves by 4-10x for common log queries, with only a 2-3% storage overhead for the Bloom filters.
Native OTLP Log Ingestion
Loki 3.0 accepts OTLP log data natively, alongside the existing Loki push API and Promtail. OpenTelemetry collector → Loki 3.0, no translation. Logs, traces, and metrics all flow through the same OTLP pipeline.
Structured Metadata (GA)
Structured metadata - key-value pairs extracted from log lines at ingestion time and stored as indexed metadata - is now GA. This was experimental in Loki 2.9. With Loki 3.0, structured metadata is the default ingestion path. Log lines become:
{
"timestamp": "2026-07-30T10:00:00Z",
"body": "request completed in 234ms",
"structured_metadata": {
"app": "api",
"method": "POST",
"status": 200,
"duration_ms": 234,
"trace_id": "abc123"
}
}
Query like {app="api"} | status=500 | duration_ms > 1000 - full relational filtering on structured metadata, with the performance of indexed labels and the flexibility of log parsing. This replaces the old pattern of creating hundreds of stream labels (which kills performance) or parsing at query time (which is slow).
TSDB Index (GA)
The TSDB-based index introduced in Loki 2.9 is now the default and only index format in Loki 3.0. BoltDB shipper is deprecated. TSDB index provides:
- 80% smaller index size compared to BoltDB
- Parallel query execution across index shards
- Time-range-optimized index pruning
Mimir 2.16: Metrics at Billion-Series Scale
Grafana Mimir 2.16 (the Prometheus-compatible long-term storage) adds:
- Native histogram query acceleration: Query native histograms 3x faster with pre-aggregated bucket indices
- Cross-zone replication: Write to Mimir across three availability zones without cross-AZ read costs on queries
- Query results caching (GA): Repeated dashboard queries hit the cache instead of TSDB - 10-50x faster
How to Upgrade
Grafana 13
# Debian/Ubuntu
wget https://dl.grafana.com/oss/release/grafana_13.0.0_amd64.deb
dpkg -i grafana_13.0.0_amd64.deb
# Docker
docker pull grafana/grafana:13.0.0
# Kubernetes (Helm)
helm repo update grafana
helm upgrade grafana grafana/grafana --set image.tag=13.0.0
Loki 3.0 (Microservices Mode)
# Helm upgrade
helm repo update grafana
helm upgrade loki grafana/loki \
--set loki.image.tag=3.0.0 \
--set loki.structuredConfig.index_type=tsdb \
--set loki.structuredConfig.bloom_filter.enabled=true
Important: Loki 3.0 requires TSDB index. If you are on BoltDB, migrate before upgrading:
# Add to Loki config and restart on v2.9 first
schema_config:
configs:
- from: "2026-01-01"
store: tsdb
object_store: s3
schema: v13
Mimir 2.16
helm upgrade mimir grafana/mimir-distributed --set image.tag=2.16.0
The LGTM Cost Comparison
At GrafanaCON 2026, Grafana Labs published a comparison of self-hosted LGTM vs Datadog for a mid-size deployment (500 nodes, 1M metrics series, 1TB logs/day, 100K spans/second):
| Component | Datadog (annual) | LGTM Self-Hosted (annual) |
|---|---|---|
| Metrics | $180,000 | $24,000 (3x Mimir nodes) |
| Logs | $360,000 | $18,000 (3x Loki nodes, S3 storage) |
| Traces | $120,000 | $12,000 (3x Tempo nodes) |
| Dashboards | Included | Included |
| Total | $660,000 | $54,000 |
The LGTM stack costs 8% of Datadog at this scale. The difference grows with ingestion volume because Datadog charges per-gigabyte-ingested while LGTM costs are driven by compute (which scales sub-linearly with volume after a baseline cluster size).
How ServerGurus Deploys LGTM
We offer managed LGTM stack deployments on our bare metal and GPU cloud infrastructure. A typical production setup:
- 3x Mimir nodes (16 vCPU, 64GB RAM, NVMe) - metrics ingestion + query
- 3x Loki nodes (8 vCPU, 32GB RAM, NVMe) - log ingestion + query
- 1x Tempo node (8 vCPU, 32GB RAM) - distributed tracing
- S3-compatible object storage - long-term retention (included with our bare metal plans)
- Grafana - co-located or dedicated node depending on dashboard load
Full deployment takes under 2 hours with our Helm-based automation. Pricing starts at Rs 24,999/month for the compute layer - storage is included with your server plan.
For teams evaluating whether to migrate from SaaS observability, we offer a 30-day free trial of the managed LGTM stack with your production data. Import your existing Grafana dashboards, point your OpenTelemetry collectors at our endpoints, and compare costs side by side.
Quick Start: LGTM on Docker Compose
# docker-compose.yml - smallest functional LGTM stack
version: "3.8"
services:
grafana:
image: grafana/grafana:13.0.0
ports: ["3000:3000"]
environment:
- GF_FEATURE_TOGGLES_ENABLE=otelDataSource
loki:
image: grafana/loki:3.0.0
ports: ["3100:3100"]
command: -config.file=/etc/loki/local-config.yaml
mimir:
image: grafana/mimir:2.16.0
ports: ["9009:9009"]
command: -config.file=/etc/mimir/config.yaml
docker compose up -d
# Grafana at http://localhost:3000
# Add Loki (http://loki:3100) and Mimir (http://mimir:9009) as data sources
Your entire observability stack - metrics, logs, dashboards, alerts - running on a single server in under a minute.