Prometheus TSDB Size Calculator
Calculate Prometheus TSDB size from total sample count and per-sample byte cost, accounting for compaction savings.
Inputs
Number of distinct active time series being scraped.
How often each series is scraped.
How long samples are retained.
Uncompressed bytes per sample (timestamp + value + overhead) before TSDB compaction.
Compression factor Prometheus's TSDB achieves via delta + XOR encoding — typical effective storage is ~1.3-2 bytes/sample after compaction, expressed here as a divisor on raw size.
Estimated TSDB Size (compacted)
49.52GB
Raw Size Before Compaction
64.37GB
Compaction Savings
14.86GB
Total Samples Over Retention
4,320,000,000
Step by step
Samples per series per day
86400 ÷ 15s
= 5760 samples/series/day
Total samples over retention window
50000 × 5760 × 15 days
= 4,320,000,000 samples
Raw size before compaction
4,320,000,000 × 16 bytes
= 64.37GB
Compacted size
64.37GB ÷ 1.3
= 49.52GB
How it works
TSDB size scales with total sample count: samples = active_series × (86400 / scrape_interval) × retention_days, and raw size = samples × bytes_per_sample. Prometheus's TSDB uses delta-of-delta timestamp encoding and XOR-based value encoding within compacted blocks, meaningfully shrinking storage versus a naive per-sample byte cost — this calculator models that as a compaction ratio applied to the raw estimate.
Formula
tsdb_size_GB = active_series × bytes_per_sample × samples_per_day × retention_days / (1024^3)
- active_series
- Number of active time series
- bytes_per_sample
- Bytes per sample after compression
- samples_per_day
- 86400 / scrape_interval_sec
- retention_days
- Data retention period (days)
Frequently Asked Questions
What's Prometheus's actual typical bytes-per-sample after compaction?
Prometheus's own documentation cites roughly 1-2 bytes per sample after compaction for typical workloads, though this varies with label cardinality, value entropy (how much values actually change between scrapes), and time range.
Why does raw size assume 16 bytes per sample?
Before compaction, each sample conceptually carries an 8-byte timestamp, an 8-byte float64 value, plus label reference overhead — 16 bytes/sample is a reasonable uncompressed baseline before TSDB's delta/XOR encoding kicks in.
Does higher cardinality change compaction efficiency?
Yes — very high-cardinality series (especially ones with volatile label sets) compact less efficiently because there's more unique label metadata to store and less opportunity for XOR encoding to find small deltas between consecutive samples.
How can I check real TSDB size on disk?
Check the size of Prometheus's `data/` directory, or query `prometheus_tsdb_storage_blocks_bytes` for the current on-disk block size directly from Prometheus's own metrics.
You might also need
- Prometheus Storage CalculatorCommonly used together
- Time Series Growth CalculatorCommonly used together
- Metrics Cardinality CalculatorCommonly used together
- Exporter Resource CalculatorCommonly used together
- Prometheus Retention CalculatorCommonly used together
- Scrape Interval CalculatorCommonly used together