Thanos Scales Prometheus

Scaling Prometheus beyond a single server is a recurring challenge for teams running large or long-lived observability estates. Thanos is a CNCF Incubating project [1] that is commonly discussed as a way to extend Prometheus retention and query scope without abandoning the Prometheus data model. The discussion below focuses on what is established about Thanos from published sources, how those properties map to scaling concerns, and where trade-offs appear when compared with alternatives such as Cortex.

Setting Up a Thanos Cluster

From an architectural perspective, teams evaluating Thanos typically think in terms of components that are named in the ecosystem — Thanos Query, Thanos Ruler, and object storage — and how they relate to existing Prometheus instances. The precise deployment topology is an operational choice, and the article avoids asserting unsupported installation mechanics.

What is supported is the high-level design intent. Thanos leverages the Prometheus 2.0 storage format to cost-efficiently store historical metric data in any object storage while retaining fast query latencies [1]. That property shapes how a cluster is reasoned about: Prometheus continues to be the local collector, and Thanos adds a layer that can make historical data accessible across installations.

The claim of leveraging the Prometheus 2.0 storage format matters for migration risk. Because the format is native, the local Prometheus server continues to operate as before for recent data. The addition of Thanos does not require re-encoding time series or changing scrape configuration in principle. The long-term data path is additive rather than replacement.

The object storage component is central to the scaling argument. Thanos can use cheap-ish object stores like Amazon S3 or Azure Blob Storage [2], while Cortex prefers more expensive NoSQL stores like AWS DynamoDB or Google BigTable to store long-term historical data [2]. The cost difference is not a guarantee of savings in a specific environment, but it is a documented design distinction that informs capacity planning discussions.

Data locality is another documented design choice. Thanos is less-centralized and data remains within each Prometheus server—which is how Prometheus operates by default [2]. That decentralization influences operational expectations. Failures are scoped to individual Prometheus instances rather than a single ingestion plane. It also means that local queries for recent windows can be served without crossing network boundaries to a central store.

The figure above is a conceptual view of data staying with each Prometheus while a query layer can access object storage. It reflects the documented claim that Thanos is less-centralized and data remains within each Prometheus server [2].

Thanos provides a global query view across all Prometheus installations and can merge data from Prometheus HA pairs on the fly [1]. The on-the-fly merging capability is described as a specific feature, not a batch reconciliation process. This property is relevant when teams run high-availability Prometheus pairs and want a single query interface without manual deduplication.

The comparison with Cortex reinforces the architectural difference. Cortex behaves like typical SaaS monitoring where data is pushed to a central location from remote servers [2]. The push model centralizes ingestion and storage. Thanos, by contrast, is described as less-centralized and data remains within each Prometheus server—which is how Prometheus operates by default [2]. The operational implication of that difference is how data movement is managed and where blast radius is contained.

Storing and Querying Metrics with Thanos

The core value proposition that is documented is storage efficiency combined with query scope.

Thanos leverages the Prometheus 2.0 storage format to cost-efficiently store historical metric data in any object storage while retaining fast query latencies [1]. This is presented as a contrast to approaches that require more expensive purpose-built stores for long-term retention.

The retention story is tied directly to object storage. By writing blocks in the Prometheus 2.0 format to object storage, Thanos can extend retention far beyond what local disk allows for a single Prometheus server without changing the query language or data model. The retention extension is therefore horizontal in time rather than requiring a different storage engine.

Query scope is also documented. Thanos provides a global query view across all Prometheus installations and can merge data from Prometheus HA pairs on the fly [1]. The ability to merge data from HA pairs on the fly is cited as a specific capability.

A global query view means a single Thanos Query component can fan out to multiple Prometheus instances and aggregate results. For engineers, this changes how dashboards and alerts are authored. Queries written against the Thanos Query endpoint can span time ranges that include both recent local data and older data stored in object storage, and can span multiple Prometheus shards.

In comparison, Cortex behaves like typical SaaS monitoring where data is pushed to a central location from remote servers [2]. Cortex prefers more expensive NoSQL stores like AWS DynamoDB or Google BigTable to store long-term historical data [2], while Thanos can use cheap-ish object stores like Amazon S3 or Azure Blob Storage [2].

The storage cost distinction is frequently cited when evaluating long-term retention. Object storage is generally priced for durability and infrequent access, whereas NoSQL stores cited for Cortex are priced for low-latency random access and managed scaling. The documented preference is a structural difference, not a benchmark result.

Thanos is less-centralized and data remains within each Prometheus server—which is how Prometheus operates by default [2]. That decentralization is frequently highlighted as an operational difference from Cortex’s centralized ingestion model.

Decentralization has consequences for consistency and availability. Because data remains local, a network partition between a Prometheus instance and object storage does not necessarily prevent serving recent data. It also means that operators retain the existing Prometheus operational patterns for scrape, rules, and alerting at the instance level. The Thanos layer adds capabilities without removing the baseline Prometheus behavior.

These documented properties inform the discussion around storing and querying: local data retention is preserved, long-term data can be offloaded to object storage, and queries can span multiple Prometheus installations.

The combination of Prometheus 2.0 storage format reuse, object storage for historical blocks, and a query layer that provides a global view across all Prometheus installations and can merge data from Prometheus HA pairs on the fly [1] forms the documented scaling story. Thanos is a CNCF Incubating project [1], and its design is described as leveraging the Prometheus 2.0 storage format to cost-efficiently store historical metric data in any object storage while retaining fast query latencies [1].

Trade-offs surface in the comparison with Cortex. Cortex behaves like typical SaaS monitoring where data is pushed to a central location from remote servers [2]. That centralization can simplify a single pane of glass but moves data ownership away from the local Prometheus. Thanos is less-centralized and data remains within each Prometheus server [2], which preserves local autonomy at the cost of more distributed operational responsibility.

The choice between cheap-ish object stores like Amazon S3 or Azure Blob Storage [2] and more expensive NoSQL stores like AWS DynamoDB or Google BigTable [2] is presented as a documented architectural difference. Teams weighing those options will evaluate cost models, durability guarantees, and query latency expectations against their own retention and query patterns.

Overall, the documented claims position Thanos as an extension of Prometheus rather than a replacement. Prometheus continues to be the local collector, Thanos adds a layer that can make historical data accessible across installations, and the query layer provides a global view while data remains within each Prometheus server.

References

1. thanos-io/thanos — github.com (7 October 2026)
2. Big Prometheus — monitoring2.substack.com (8 January 2020)