Prometheus Storage & Retention Calculator
Estimate the local Prometheus disk needed for a retention target, then compare it with the disk you have. You can calculate ingestion from active series and scrape interval or use an observed samples-per-second rate.
Recommended allocated disk (GiB)15.09
- Total ingestion rate (samples/second)
- 6,666.67
- Samples stored per day
- 576,000,000
- Estimated TSDB data (GiB)
- 12.07
- Recommended retention-size limit
- 80 GiB (--storage.tsdb.retention.size=80GB)
- Maximum retention on available disk (days)
- 99.42
- Disk margin at target retention (GiB)
- 84.91
- Suggested Prometheus flags
- --storage.tsdb.retention.time=15d --storage.tsdb.retention.size=80GB
Uses 1.5 compressed bytes per sample and reserves 20% of the allocated disk for compaction.
Prometheus removes data when either the time or size retention limit is reached first.
How to use this calculator
- Choose active series and scrape interval, or measured samples per second, as the ingestion method.
- Include any extra samples produced by recording rules or received through remote write.
- Enter the local retention target, estimated compressed bytes per sample, and allocated disk capacity.
- Reserve compaction headroom, then use the size limit and flags as a conservative starting point.
How Prometheus storage is estimated
Prometheus documents a rough capacity formula for compacted local samples: disk bytes = retention seconds × ingested samples per second × bytes per sample. This calculator uses that formula for the estimated TSDB data, then adds a disk allowance for compaction.
With active-series input, the base ingestion rate is active series ÷ scrape interval. With measured-rate input, it is the rate you enter. In either case, additional ingestion is added after that: s = q + x. The retained sample data is B = days × 86,400 × s × b, where b is compressed bytes per sample. The result is divided by 2^30 to show GiB.
The recommended allocated disk is B ÷ (1 − h ÷ 100). The same usable fraction is applied to your existing disk to produce a retention-size setting. The setting is rounded down to two decimals so it cannot exceed the safe capacity.
What moves the estimate most
Ingestion rate and retention time have a direct, linear effect. Doubling either doubles the compacted sample estimate. When you calculate from series, cutting the scrape interval from 30 seconds to 15 seconds doubles the estimated rate. Removing high-cardinality or unneeded series can reduce storage more effectively than changing the interval because it also reduces index and operational work.
Prometheus says compacted samples average about 1–2 bytes each, but the right value for a particular installation depends on its data and version. If you can measure disk growth over a representative period, use that observation to refine the bytes-per-sample assumption and the measured ingestion rate.
Why the calculator leaves disk free
During compaction, source blocks and a newly compacted block can coexist. Prometheus recommends setting storage.tsdb.retention.size to no more than 80–85% of allocated disk for this reason. A 20% headroom is the default here. Prometheus accepts size units such as GB as powers of two, so the suggested flag corresponds to the displayed GiB amount.
When time and size retention are both set, Prometheus applies whichever limit is reached first. The time flag shown preserves the requested policy, while the size flag protects the allocated disk. A size limit can therefore cause retention to be shorter than the target when ingestion rises.
What this estimate does not model
This is an estimate of compacted sample storage, not a full filesystem budget. Prometheus also uses WAL segments, head chunks, indexes, tombstones, and space during delayed cleanup; WAL and head data can be materially larger than compacted blocks. Native histograms, exemplars, label churn, filesystem overhead, and remote storage costs are outside this calculation. Validate the estimate against real disk growth before committing to a long retention period.
Worked example
Suppose Prometheus ingests 100,000 active series every 15 seconds, has no additional sources, retains data for 15 days, and averages 1.5 bytes per sample. Its estimated rate is 100,000 ÷ 15 = 6,666.67 samples per second, or 576,000,000 samples per day.
The raw estimate is 15 × 86,400 × 6,666.67 × 1.5 = 12,960,000,000 bytes, or 12.07 GiB. With 20% compaction headroom, the recommended allocated disk is 15.08 GiB. On a 100 GiB allocation, a conservative retention-size setting is --storage.tsdb.retention.size=80GB, and the target leaves about 84.92 GiB of margin.
Common questions
How much disk space does Prometheus need?
For compacted samples, multiply retention seconds by ingested samples per second and bytes per sample. Allocate more than that result because compaction temporarily needs extra space; Prometheus recommends retaining no more than 80–85% of the allocated disk by size.
How do I find Prometheus samples ingested per second?
You can estimate it from active series divided by scrape interval. On a running server, a rate over a representative window of prometheus_tsdb_head_samples_appended_total gives a more direct measurement. Include samples from recording rules and remote-write receiving if they are stored locally.
How do active series and scrape interval affect storage?
At a fixed interval, more active series create proportionally more samples. At a fixed series count, a shorter interval also creates proportionally more samples: 15-second scraping stores twice as many samples as 30-second scraping. Compression makes the exact disk outcome less linear, but this is the planning estimate.
What bytes-per-sample value should I use?
Prometheus documents a rough average of 1–2 bytes per compacted sample, so 1.5 is a reasonable initial estimate. Replace it with an observation from your own stable workload when possible, especially if you have high churn, unusual metric types, or frequent histogram samples.
Why should Prometheus disk retain 15–20% free space?
Compaction writes a new block before its source blocks are removed, so disk use can briefly exceed the retained block size. Prometheus recommends limiting retention size to 80–85% of allocated disk to leave room for that temporary growth and for cleanup timing.
What is the difference between retention time and retention size?
Retention time removes sufficiently old data, while retention size removes old persistent blocks when their size reaches the limit. If both are configured, Prometheus uses whichever condition is met first. That makes the size setting a safety cap, not a promise that the full time period will always be retained.