You're not looking for a better tool. You're looking for a way out.

  • Metrics in Prometheus.

  • Logs in Loki.

  • Traces in Elasticsearch.

  • Three systems, three bills, three pager rotations.

  • GreptimeDB handles all three - in one engine, on object storage.

Comparison banner diagram

The problem isn't your metrics tool.
The problem is running three separate systems.

OBSERVABILITY 1.0

Three tools, three problems

  • Separate ingestion pipelines per signal
  • No cross-signal correlation in a single query
  • Scale = more components, more ops
  • Storage sprawl across local disks
  • Three dashboards, three alert configs
VS

OBSERVABILITY 2.0

One engine, Wide Events

  • Single OTLP endpoint for all signals
  • JOIN metrics + logs + traces in one SQL query
  • Scale = stateless compute nodes on S3
  • Object storage as primary - up to 50x cheaper
  • One datasource, one operational surface

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 separation — 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
  • 10x query performance in benchmark tests
  • 30% lower storage cost, same Grafana datasource
Compare in depth→

Traces / Logs

Elasticsearch

Inverted indexes were built for text search, not trace storage. Storage inflates up to 45x.

GREPTIMEDB ADVANTAGES

  • Columnar storage + object storage — inverted index is wasteful for traces
  • 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. Better than the Grafana stack — but still three systems.

GREPTIMEDB ADVANTAGES

  • One engine — JOIN across all signals in a single query
  • Single ingestion endpoint, single operational surface
  • 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
  • Timestamp-first storage layout, built for time-series access patterns
  • Dynamic schema — new span attributes auto-create columns
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.

Redirect ingestion

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

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

All Comparisons

Side-by-side feature breakdowns for additional alternatives.

Prometheus

Grafana Loki

ElasticSearch

Victoria Stack

ClickHouse

Apache Druid

Apache IoTDB

Apache Pinot

Grafana Tempo

InfluxDB

M3DB

QuestDB

TDEngine

TimescaleDB