GreptimeDB vs. Grafana Loki

Promtail pushed it.
Loki indexed labels only.

CHALLENGER

Grafana Loki

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

GreptimeDB

Full-text index + SQL for logs, unified with metrics and traces

Full-text index — keyword search 40-80x faster in [benchmark tests](/blogs/2025-08-07-beyond-loki-greptimedb-log-scenario-performance-report)
Sub-second queries across hours/days of log data
Unified engine for logs, metrics, and traces in one system

Loki Stack

4-7 COMPONENTS

Promtail / Fluent Bit / Vector

collect + parse + ship

Loki Distributor + Ingester

write + chunk

Index Gateway + Querier

fan-out query

Compactor + Object Storage

retention + optimize

GreptimeDB

1 DATABASE

Frontend node (stateless, auto-scale)

query + ingest gateway

Datanode (compute, stateless)

native object storage

LogQL-like migration path via Loki Push API
Full-text + structured query in SQL
Scale compute and storage independently

Feature comparison

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.

Redirect ingest endpoint

Docs

Switch Promtail / Fluent Bit / Vector output to GreptimeDB Loki Push API endpoint with no downtime.

30 min

Grafana datasource

Docs

Replace Grafana datasource to GreptimeDB. Existing explore workflows and dashboards continue to work.

1 hour

Backfill historical logs

Export log chunks from object storage and bulk import to GreptimeDB while live ingestion continues.

1-3 days

Decommission Loki cluster

After data validation, gradually turn off Loki components and keep GreptimeDB as the primary log backend.

2 Weeks

OceanBase

Staff Engineer

Learn more

Migrating from Loki to GreptimeDB enables high-performance querying of massive log data at scale, offers multi-cloud deployment flexibility, and significantly simplifies application and deployment architecture.