Struggling to scale Prometheus?
There's a structural fix.
Prometheus scraped it. Thanos archived it. Mimir distributed it. You're running three systems to do one job. The multi-value model Prometheus lacks, SQL correlation you've been wanting, a unified cost model for metrics + logs — these aren't add-ons. They're reasons the three-pillar model is over.
CHALLENGER
Pull-based scraper · PromQL only · 5-8 components to scale
High ops overhead at scale
Siloed metrics workflow for broader observability
Single-value series only, no multi-value rows
Deep analysis requires exporting to a separate data warehouse
GREPTIMEDB
Metrics + Logs + Traces · SQL + PromQL · Native object storage
One database, compute-storage disaggregated scale-out
SQL + PromQL on top of object storage
Multi-value rows: tags, timestamp, and fields
Replace Prometheus + data warehouse with one system
Why scaling Prometheus means adding components - and why GreptimeDB doesn't.
5-8 COMPONENTS
remote write
compact + index
query fan-out
long-term
1 DATABASE
compute-storage disaggregation
native object storage
| Dimension | GreptimeDB | Prometheus | Thanos / Mimir |
|---|---|---|---|
| Query language | SQL + PromQL (dual) | PromQL only | PromQL only |
| Data model | Multi-value rows: tags, timestamp, fields | Single-value time series | Single-value time series |
| Data types | Metrics + Logs + Traces | Metrics only | Metrics only |
| Storage | Native object storage (S3, OSS, GCS) | Local disk | Object storage via sidecar (Thanos) or native (Mimir) |
| Scaling model | Compute-storage disaggregation, stateless | Federation only | Multi-component (ops heavy) |
| OpenTelemetry | Native OTLP (all signals) | Metrics only (remote write) | Metrics only (Thanos); OTLP metrics supported (Mimir) |
| Continuous aggregation | Built-in SQL aggregation + Flow streaming engine | Recording rules (limited) | Recording rules (limited) |
| High availability | Native clustering with automatic failover | Requires manual federation | Multi-component HA setup |
| License | Apache 2.0 | Apache 2.0 | Thanos: Apache 2.0; Mimir: AGPLv3 |
| Migration effort | PromQL-compatible, remote write ready | — | Requires infra redesign |
Thanos and Mimir have different architectures. This column summarizes common patterns.
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.
PromQL-compatible. Remote write ready. No rewrite required.
Read the migration guide→Point Prometheus remote_write to GreptimeDB endpoint. Zero downtime. Existing scrape configs untouched.
30 min
Replace Grafana datasource — GreptimeDB exposes a Prometheus-compatible API. Existing dashboards work immediately.
1 hour
Export historical data from Thanos snapshots or promtool. Bulk insert via gRPC without impacting live writes.
1-3 days
After data validation, shut down Thanos Sidecar, Compactor, and Store Gateway one by one.
2 Weeks
Side-by-side feature breakdowns for additional alternatives.
Stay in the loop
Get the latest updates and discuss with other users.
