Promtail pushed it.
Loki indexed labels only.
Grafana Loki is a horizontally scalable, multi-tenant log aggregation system inspired by Prometheus. Loki indexes only label metadata — not the log content itself. This keeps storage cheap, but means every log body query is a brute-force scan. At scale, that trade-off becomes a ceiling: large queries time out, search is limited to minutes of data, and ad hoc troubleshooting slows down. Click here to read the full performance comparison report between GreptimeDB and Loki.
CHALLENGER
Label-first logging stack that scales well but limits ad hoc text analytics
Label-only index — log body search is brute-force at scale
Large queries time out, search range limited to minutes
Separate systems still needed for metrics and traces
GREPTIMEDB
Full-text index + SQL for logs, unified with metrics and traces
Full-text index — keyword search 40-80x faster in benchmark tests
Sub-second queries across hours/days of log data
Unified engine for logs, metrics, and traces in one system
Why scaling Loki-based logging adds pipeline complexity - and why GreptimeDB stays simpler.
4-7 COMPONENTS
collect + parse + ship
write + chunk
fan-out query
retention + optimize
1 DATABASE
query + ingest gateway
native object storage
| Dimension | GreptimeDB | Grafana Loki |
|---|---|---|
| Indexing strategy | Full-text index + inverted index + secondary index | Label-based indexing only (no full-text) |
| Query language | SQL + PromQL (dual interface) | LogQL |
| Data types | Metrics + Logs + Traces in one database | Logs only (separate systems for metrics/traces) |
| Query performance | Sub-second with full-text search (40-80x on keyword queries) | Fast label queries, brute-force text search at scale |
| Log processing | Built-in Pipeline engine for parsing and transformation | Basic parsing with structured metadata |
| Storage format | Apache Parquet (columnar, compressed) | Custom chunks (compressed log streams) |
| Storage architecture | Compute-storage disaggregation, native object storage | Distributed with object storage backends |
| Ingestion protocols | SQL, gRPC, OTLP, Loki Push API, Elasticsearch Bulk API, HTTP | HTTP Push API, Promtail, Fluent Bit, Vector |
| OpenTelemetry | Native OTLP (all signals) | Native OTLP log ingestion supported; query model still label-index-based |
| License | Apache 2.0 | AGPL 3.0 |
| Operational complexity | Single system for all observability data | Requires Mimir + Tempo for complete observability |
Performance data from benchmark tests. Results vary by workload and configuration. See the full benchmark report.
Agent RCA Bench. In 504 end-to-end root cause investigations — six models, 14 incidents, model and prompt held fixed, the complete interface bundle as the variable — querying Prometheus, Loki, and Tempo through their native APIs produced 105 correct diagnoses out of 168, against 130 through GreptimeDB, at about 48% less input read. Storage, query language, and tool design change together, so the comparison does not isolate any one of them. Diagnosis accuracy was not a pre-specified endpoint and is reported as descriptive; the pre-specified endpoints and their separate correction families are in the report. Scoring uses no LLM judge. Greptime sponsors and maintains the benchmark, and the code and artifacts reproduce the published results byte for byte. See the full report and the writeup.
Loki Push API compatible. Keep existing agents, migrate step by step.
Read the dual-write migration guide→Switch Promtail / Fluent Bit / Vector output to GreptimeDB Loki Push API endpoint with no downtime.
30 min
Replace Grafana datasource to GreptimeDB. Existing explore workflows and dashboards continue to work.
1 hour
Export log chunks from object storage and bulk import to GreptimeDB while live ingestion continues.
1-3 days
After data validation, gradually turn off Loki components and keep GreptimeDB as the primary log backend.
2 Weeks
Side-by-side feature breakdowns for additional alternatives.
Stay in the loop
Get the latest updates and discuss with other users.
