Thanos

What it is

Thanos extends Prometheus with long-term storage, global query federation, and high availability. It solves three specific problems Prometheus doesn't handle natively: retaining metrics beyond local disk limits, querying across multiple Prometheus instances/clusters as a single pane of glass, and deduplicating data from redundant Prometheus pairs. It does this by shipping blocks to object storage (S3, GCS, Azure Blob, etc.) and layering a query engine on top that understands both local and remote data.

Architecturally it's a set of independent components — Sidecar, Store Gateway, Compactor, Querier, Receiver, Ruler — that you deploy based on your needs. You don't need all of them. This modularity is a strength and a source of operational complexity depending on how you use it.

Who builds it and why

Thanos started at Improbable to solve their own multi-region Prometheus scaling problem, then moved to CNCF where it's now incubating. The 730 contributors and steady commit cadence (latest activity July 2026, v0.41.0 release) indicate this isn't a single-vendor side project — it's maintained by a broad set of engineers from companies that run Prometheus at scale and hit its single-node limitations directly. Red Hat, Grafana Labs alumni, and various platform teams have historically been heavy contributors, though current org affiliation breakdown is not publicly available.

Production readiness signal

14,130 GitHub stars and 730 contributors on a CNCF incubating project is a strong signal — this is well past the "interesting side project" phase. Commit activity through mid-2026 shows the project is actively maintained, not coasting. Apache-2.0 licensing removes legal friction for enterprise adoption.

What the numbers don't tell you: Thanos has a reputation for being operationally heavy. The Compactor in particular requires careful sizing and monitoring — get it wrong and you get either unbounded object storage growth or corrupted blocks. This isn't a criticism unique to Thanos; it's the cost of the architecture. Teams running it in production for 2+ years generally report it as stable once properly tuned, but the tuning period is real.

Who should use this

• Teams running Prometheus across multiple clusters or regions who need a single query interface
• Organizations that need to retain metrics for months or years for compliance, capacity planning, or trend analysis, and don't want to scale Prometheus local disk to do it
• Platform teams already comfortable operating stateful distributed systems and object storage
• Anyone who needs Prometheus HA (two replicas, deduplicated) without gaps during restarts or deploys

Who should NOT use this

• Single-cluster shops with modest retention needs — Prometheus alone with a reasonably sized disk will outperform Thanos in simplicity and operational cost
• Teams without object storage expertise or budget — S3/GCS costs and IAM configuration are not optional extras, they're core to the architecture
• Small platform teams (1-2 engineers) without dedicated observability ownership — the Compactor and Store Gateway both require monitoring and tuning attention that competes with other priorities
• Anyone expecting a fully managed experience out of the box — Thanos is a toolkit, not a product. If you want managed long-term Prometheus storage without running the components yourself, look at a hosted alternative instead

Alternatives

• Grafana Mimir — Cortex's successor, similar long-term storage goals, generally considered easier to operate at scale with a more opinionated single-binary deployment model.
• VictoriaMetrics — simpler operational model, often cited as lower resource overhead for comparable retention and query performance, but smaller ecosystem and less CNCF governance.
• Cortex — the original horizontally-scalable Prometheus storage project Thanos and Mimir both descend from conceptually; still maintained but has lost mindshare to Mimir.

Pricing

Fully open source, Apache-2.0. No paid tier, no vendor lock-in on the project itself. Your actual cost is object storage (S3/GCS/Azure) usage plus the compute for running Store Gateway, Compactor, and Querier — budget for this explicitly, it's not free just because the software is.