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.
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.
