InfluxDB storage and retention sizing calculator

How this sizing estimate is built

The calculation is deliberately short. Every line below is reproduced with your own numbers in the “show the arithmetic” panel after you run the estimate, so you can check it or repeat it in a spreadsheet:

• Points per second = devices ÷ write interval. Fields do not change the point count — they ride along in the same point.
• Points kept = points per second × 86,400 × retention in days.
• Uncompressed model = points kept × (8 bytes of timestamp + field count × field width), times the replica count. This is the shape of the data, not what InfluxDB writes.
• Stored size = points kept × bytes per stored point × replicas, with a ×0.7 and ×1.4 band around it.
• On disk = stored size + your overhead allowance, and the provisioned figure adds your headroom and rounds up to the next disk size a person would actually buy.

What the numbers mean in practice

Calibrate the assumption against your own instance

The bytes-per-point field is the only thing on this page that is a judgement rather than arithmetic, so it is worth replacing with a measurement. On the machine running InfluxDB, take the size of the data directory and divide it by the number of points you actually keep:

• InfluxDB 1.x: du -sh /var/lib/influxdb/data then compare with the total point count from your measurements.
• InfluxDB 2.x / 3.x OSS: the same idea on the engine directory (/var/lib/influxdb2/engine by default).
• A home installation with regular one-minute writes usually lands between 1.5 and 3 bytes per point. If your figure is far above 4, the usual causes are many short-lived series, wildly irregular timestamps, or string fields that never repeat.

Our own bench runs 46 Zigbee devices with several recorded fields each and more than 400 million rows of history in a self-hosted InfluxDB VM — the Home Assistant preset above starts from that device count, so you can see what the same arithmetic says about it before you plan your own.

Limitations

• This is a sizing estimate, not a reading from your server. It never queries InfluxDB and cannot see your actual series cardinality, shard layout or compaction state.
• Only the stored bytes are modelled. Memory, CPU and query performance are separate questions — a workload with many series costs RAM long before it costs disk.
• The overhead field is a single allowance, not a breakdown: the write-ahead log, the series index and the file system slack are folded into one number you control.
• Units are decimal. 1 GB on this page is 10⁹ bytes, matching what a disk vendor prints, not the 2³⁰ a file manager may show.
• Downsampling, continuous queries and tasks change the retention maths — if you keep raw points for a month and roll-ups for years, size the two windows separately and add them.

FAQ

How accurate is this InfluxDB sizing estimate?

The point count is exact arithmetic on what you type: devices × writes per day × retention days. The disk figure is that point count multiplied by one heuristic — bytes per stored point — and everything else on the page is derived from those two numbers. Treat the result as a disk-order-of-magnitude, then calibrate it: run du -sh on your InfluxDB data directory, divide by the points you actually store, and put that figure back into the bytes-per-point field.

Why is the compression assumption editable?

Because it is the only part of the calculation that depends on your data rather than on your settings. InfluxDB delta-encodes timestamps and XOR-encodes floats, and how well that works depends on how regular your writes are, how many series you scatter them across and how many fields change between points. The default of 2.5 bytes per point is the middle of the range field reports usually land in; the lean and conservative rows show what happens at 1.5 and 4 bytes.

Does a retention policy keep storage flat forever?

Yes — once the oldest data reaches the retention window, every point written evicts a point, so the size stops growing. The growth table shows the ramp up to that steady state year by year, with the final row capped at your retention window, so you can see whether you are sizing for the ramp or the plateau.

What is the difference between the uncompressed and stored figures?

The uncompressed figure is the naive shape of the data: 8 bytes of timestamp plus the field values, multiplied by every point you keep. InfluxDB stores far less than that because timestamps delta-encode and floats compress, so the stored figure is the realistic one. The gap between them is the implied compression ratio printed next to the result.

Should I add replicas or overhead?

Use replica copies of 1 for a single InfluxDB OSS instance. Raise it only if you genuinely write the same points to more than one server. The overhead field covers the write-ahead log, the series index, the file system and the slack inside TSM files; 10% is a reasonable allowance for a local SSD, and the safety headroom is what you leave free so a compaction or a backfill does not fill the disk.

Does this calculator connect to my InfluxDB server?

No. There is no query, no API call and no upload — the page is arithmetic in JavaScript over the numbers you type. You can load it, run the estimate and disconnect before submitting the form and the result is identical.