A local Prometheus stores its metrics on the disk of the node it runs on, with retention generally configured for a few weeks: beyond that, old data gets purged, not archived. This constraint isn’t a configuration oversight, it’s a structural limit of the model: a local TSDB isn’t designed to hold years of history, nor to answer a query spanning several distinct Prometheus clusters at once.

Local retention, bounded by the node’s disk

Every Prometheus manages its own local storage, sized to the disk space available on the node hosting it. Keeping a full year of history would mean sizing that disk accordingly, an approach that doesn’t scale past a few weeks to a few months, depending on the monitored system’s actual cardinality.

# Typical default retention: a few weeks,
# beyond that the oldest blocks get deleted
--storage.tsdb.retention.time=15d

A multi-month trend analysis (slowly growing capacity, annual seasonality) simply becomes impossible once the corresponding data has been purged, with no warning at the moment of the purge itself.

The Thanos sidecar: uploading to object storage without changing Prometheus

Thanos adds a sidecar to every existing Prometheus, without modifying its base configuration: this sidecar periodically uploads already-written TSDB data blocks to object storage (S3, GCS, or equivalent), where retention no longer has a practical limit tied to a single node’s disk.

# The Thanos sidecar runs alongside Prometheus,
# with no change to its existing scrape configuration
containers:
  - name: prometheus
    image: prom/prometheus
  - name: thanos-sidecar
    image: thanosio/thanos
    args:
      - sidecar
      - --objstore.config-file=/etc/thanos/objstore.yaml

Object storage costs structurally less per gigabyte than fast disk attached to a node, which makes multi-year retention financially realistic where it wasn’t on local disk alone.

The global view: querying multiple Prometheus instances as one

The second problem Thanos solves is distinct from retention: a cluster running several Prometheus instances (one per region, one per team) natively allows no query spanning all of them at once. The Thanos Querier component exposes a single PromQL-compatible API that queries every known Prometheus in parallel (via their sidecars) and merges the results, giving the illusion of a single global Prometheus.

# A single query, executed in parallel across every
# known Prometheus, merged into one result
sum(rate(http_requests_total[5m])) by (region)

Downsampling: trading precision for affordable history

Keeping data at native resolution (one point every 15 or 30 seconds) for several years represents a considerable object storage volume, even at a lower cost per gigabyte. Thanos applies automatic downsampling to older data (aggregated to 5 minutes, then to 1 hour past a certain age), a deliberate trade-off: long-term trends stay visible, second-by-second detail on a two-year-old incident doesn’t, a trade-off rarely relevant for that kind of history anyway.

Takeaway

A local Prometheus is structurally limited in retention by the disk of the node hosting it, a constraint that becomes a real problem the moment a trend analysis exceeds a few weeks. Thanos solves this via a sidecar offloading TSDB blocks to object storage, at a far lower cost per gigabyte, while also solving a second, distinct problem: a unified query view across several separate Prometheus instances. Automatic downsampling makes that long-term retention affordable, at the cost of reduced precision on older data, a trade-off that becomes necessary the moment reliability and observability needs to hold up across several clusters and years of history, not just a single short-memory cluster.