Skip to content

Compare GreptimeDB with the observability backends you run today

  • Metrics, logs, and traces in one columnar engine, backed by object storage.

  • See the architecture, migration path, and benchmark evidence for each alternative.

Comparison banner diagram

The question isn't which metrics tool is best.
It's whether the three backends need to stay separate.

THREE SYSTEMS

Three backends, three scaling models

  • Ingestion and retention are configured per signal
  • Each backend scales and fails differently
  • Cross-signal investigation spans multiple query languages
  • At scale, real-time monitoring and historical analysis need separate capacity plans
  • More components to deploy, upgrade, secure, and observe
VS
ONE ENGINE →

One engine, one table model

  • Metrics, logs, and traces share one table model: tags, timestamp, fields
  • Store raw events and derive metrics on demand, or materialize them continuously with Flow
  • Correlate signals in one SQL query when they carry common identifiers
  • Recent data and long retention are served by the same engine — no separate analytics stack
  • Up to 50× lower storage cost through compression and object storage

In-depth comparisons

Each page covers architecture differences, migration path, and real benchmark data.

Metrics

Prometheus / Mimir / Thanos

Running Distributor + Ingester + Compactor + Store-Gateway + Querier just to scale one metrics store?

GREPTIMEDB ADVANTAGES

  • Native compute-storage disaggregation — no Thanos sidecars needed
  • PromQL + SQL — replace your metrics data warehouse too
  • Remote Write compatible, 30-min redirect to start
Compare in depth

Logs

Grafana Loki

Loki indexes only labels. Every log body query is a full brute-force scan — and at scale, it times out.

GREPTIMEDB ADVANTAGES

  • Full-text index — no more brute-force log body scans
  • 40–80x faster keyword search in benchmarks
  • 60%+ lower storage cost in production (OceanBase Cloud)
Compare in depth

Traces / Logs

Elasticsearch

Inverted indexes optimize for text search. For trace storage the overhead adds up — up to 45x more storage on our trace benchmark.

GREPTIMEDB ADVANTAGES

  • Columnar + object storage — flexible indexing for efficient trace and log retrieval
  • Jaeger UI compatible out of the box — no dashboard rewrites
  • Apache 2.0 licensed (ES is ELv2 / SSPL / AGPLv3)
Compare in depth

Metrics / Logs / Traces

Victoria Stack

VictoriaMetrics + VictoriaLogs + VictoriaTraces — three products optimized per signal, three systems to operate.

GREPTIMEDB ADVANTAGES

  • One engine — JOIN across all signals in a single query
  • One storage backend behind your existing protocol endpoints
  • Object storage first vs local-disk architecture
Compare in depth

Analytics / OLAP

ClickHouse

Great analytics engine. Observability runs on ClickStack, a separate layer from the OLAP core.

GREPTIMEDB ADVANTAGES

  • PromQL, OTLP, Jaeger in one binary
  • Purpose-built for observability — one stack for alerting and long-term analysis
  • Object-storage-native, elastic scale-out; Enterprise adds automated repartitioning
Compare in depth

A gradual path in, not a big bang migration

Start with whichever signal is causing the most pain today. Ingestion redirect takes minutes. Full migration depends on protocol compatibility.

Read the migration guides

Redirect ingestion

Docs

Point your write endpoints (Remote Write, OTLP, Loki Push API) to GreptimeDB. Works for metrics, logs, and traces. Zero downtime.

~30 min

Migrate dashboards and queries

Docs

PromQL / Jaeger-compatible stacks — swap datasource, hours. Others — use built-in dashboards or migrate queries, days to weeks.

Hours to weeks

Backfill and decommission

Export historical data and bulk import into GreptimeDB. Validate, then decommission old systems one by one.

Days to weeks