Thanos is a CNCF Incubating, Apache-2.0-licensed collection of Go components that composes a highly available metric system with unlimited storage capacity on top of an existing Prometheus deployment.

What it is

Thanos is a set of components that can be composed into a highly available metric system with unlimited storage capacity, and it can be added seamlessly on top of existing Prometheus deployments. It lives in the cloud native monitoring ecosystem, alongside and on top of Prometheus, and it is a CNCF Incubating project written in Go. Rather than replacing Prometheus, it extends it: Thanos leverages the Prometheus 2.0 storage format to store historical metric data in object storage cost-efficiently while retaining fast query latencies, and it provides a global query view across all Prometheus installations.

The concrete problem Thanos solves is the two limits that a plain Prometheus deployment imposes. The first is retention: a Prometheus server keeps metrics on local disk, so the operator must choose between disk cost and history. The second is locality: each Prometheus answers only for the data it holds, so queries against several Prometheus servers, clusters, or a HA pair return separate and duplicated answers. Thanos addresses both by writing historical blocks to object storage for effectively unlimited retention and by presenting one query endpoint that deduplicates and merges results from every connected Prometheus server. The project states three aims directly: a global query view of metrics, unlimited retention of metrics, and high availability of components, including Prometheus.

Key capabilities

• Global querying view across all connected Prometheus servers, with thanos query proxying incoming calls to known Store API endpoints and merging the result.
• Deduplication and merging of metrics collected from Prometheus HA pairs, so a redundant pair reads as one consistent series set.
• Unlimited retention of metrics by storing historical data in any object storage, which the README describes as the only, optional dependency; the project topics list S3 and Google Cloud Storage.
• Downsampling of historical data for massive query speedup, keeping long-range queries responsive as retention grows.
• A simple gRPC "Store API" for unified data access across all metric data, with easy integration points for custom metric providers.
• Cross-cluster federation and fault-tolerant query routing for multi-cluster and multi-region metric estates.
• Two documented deployment shapes: a sidecar pattern for Kubernetes, and Receive to scale out or to implement with other remote write compatible sources.

Who uses it and how

• Kubernetes operators running Prometheus in-cluster who deploy the sidecar pattern and keep queries against local Prometheus unchanged while shipping blocks to object storage.
• Teams running Prometheus HA pairs that need one deduplicated answer instead of two near-identical ones.
• Organisations with several clusters or regions that need a single global query view and cross-cluster federation rather than per-cluster dashboards.
• High-volume or non-Prometheus producers that use the Receive component to scale out or to accept other remote write compatible sources.
• Long-retention users who accept an object storage bucket as the price of keeping years of metric history queryable.

Getting started

The README points to the Getting Started guide hosted at thanos.io, and the project ships as the Go module github.com/thanos-io/thanos, documented on pkg.go.dev. The repository is also prepared for Gitpod and GitHub Codespaces as ready-to-code environments for working on the source.

How it compares

No list of paid products that Thanos replaces is provided in the facts, and the material names no directly comparable registry entry. On the facts available, it stands alone in this registry as a Prometheus-adjacent scaling and long-term-storage layer rather than a replacement for Prometheus itself.

When to use it — and when not to

A self-hoster must operate the composed components, the gRPC Store API endpoints between them, and an object storage bucket, so object storage is optional only if long retention is not wanted. Anyone running a single small Prometheus with short retention and no multi-cluster query need should not take on that operational surface, since the problem Thanos solves is not present. The honest weakness in the facts is that the README excerpt is an overview whose subcommand detail is truncated, and the project carries 908 open issues against 14,205 stars and 2,367 forks, so evaluation should start from the Getting Started and Design documents rather than the README alone.