Skip to main content
In this guide we cover Prometheus long-term storage: how Prometheus stores time series locally, how to tune retention, how to plan capacity, and how to move data off the local disk using remote read/write or long-term storage systems (Thanos, Grafana Mimir, etc.). Prometheus writes collected samples into a block-based TSDB on local storage. Blocks are created every two hours by default and stored on the server where Prometheus runs. You can customize the directory Prometheus uses with the --storage.tsdb.path flag:
A Prometheus data directory typically contains multiple two-hour blocks. Each block contains subcomponents such as chunks (the actual compressed metrics), an index (for metric names and label lookups), meta.json, and optional WAL/checkpoint files:
  • chunks: compressed time series samples.
  • index: label and metric name indexes for fast lookups inside the block.
  • meta.json: block metadata (time ranges, version, etc.).
  • tombstones: records of deleted series.
  • wal and chunks_head: write-ahead log and in-progress chunk data.
Callout about retention defaults and tuning:
Prometheus stores recent data on local disk by default. Tune retention by time (--storage.tsdb.retention.time) or by size (--storage.tsdb.retention.size) depending on whether you want to limit based on age or storage consumption.

​
Retention: defaults and flags

By default Prometheus keeps approximately 15 days of samples locally and a retention size of 10 GB. You can change these defaults:
  • Retention time:
  • Retention size:
Use either time or size (or both). When a limit is reached, the oldest blocks are deleted. Table: common TSDB flags and examples Warning about retention and disk usage:
If retention flags are not configured according to your ingestion rate, Prometheus may delete data unexpectedly or exhaust disk space. Always plan capacity and monitor disk usage.

​
Capacity planning

Estimate disk space needed using this formula: disk required = retention time (seconds) × ingested samples per second × bytes per sample
  • A Prometheus sample typically ranges from ~1–2 bytes for compacted storage, but real-world bytes per sample vary based on label cardinality and compression.
  • For accurate planning, measure your average samples/sec and bytes/sample during representative load.
The image illustrates a capacity planning formula for calculating needed disk space, which is determined by multiplying retention time (seconds), ingested samples per second, and bytes per sample.

​
Why local storage doesn’t scale for long-term retention

The simplest way to retain data longer is to attach more block-style disk to the Prometheus server. However:
  • Block storage can be expensive at scale.
  • Prometheus’ TSDB is designed to write to a single local path; it does not horizontally distribute block storage across multiple Prometheus instances.
These limitations make local-only retention impractical and costly for multi-year storage.
The image illustrates the issues with local storage, highlighting that increasing storage is expensive and lacks horizontal scaling.
Prometheus expects to write to one location and does not natively shard block storage across servers:
The image depicts a diagram titled "Issues With Local Storage" showing three servers connected to a symbol on the left, resembling a torch icon.

​
Remote Read and Remote Write

To avoid the costs and limits of local block storage, Prometheus supports:
  • remote_write — stream samples to a remote system or long-term storage.
  • remote_read — query historical data from a remote store.
This allows you to push metrics to object storage (S3, Azure Blob), or to scalable TSDB systems (InfluxDB, VictoriaMetrics, Thanos, Grafana Mimir). Example remote write/read configuration (Prometheus YAML):
The image is a diagram illustrating a "Remote Read and Write" setup for data, featuring Prometheus writing data to remote storage options like InfluxDB.
Remote write can be combined with relabeling (write_relabel_configs) to reduce cardinality or route specific metrics to particular remote systems.

​
Long-term storage systems (Thanos, Grafana Mimir, etc.)

Many open-source and commercial tools exist to provide cost-effective long-term storage for Prometheus data. These systems typically:
  • Receive replicated data via remote_write or ingest Prometheus blocks.
  • Store compacted data in cheap object stores (S3, Azure Blob).
  • Offer queriable APIs that Prometheus or external query layers can use.
Popular systems include Thanos and Grafana Mimir, and other TSDBs like VictoriaMetrics or InfluxDB are commonly used for long-term retention.
The image depicts a flowchart on long-term storage solutions, featuring tools such as Grafana Mimir and Thanos, and remote storage options including InfluxDB and Victoria Metrics.
Note for certification or overview-level knowledge:
For exams or conceptual understanding, you only need to know that tools like Thanos and Grafana Mimir exist to provide long-term, cost-effective storage for Prometheus metrics. Deep internals of those systems are not required for basic certification-level knowledge.

Watch Video