The storage question arrives late and in the wrong form. Somebody asks how big the database needs to be, a figure is produced by multiplying points by samples by bytes by years, and the project proceeds on it. Then the first year of operation produces several times that volume, and the response is either an emergency expansion or a quiet decision to start deleting history that somebody had promised would be kept.
The message up front: the naive calculation is right about the shape and wrong about the magnitude, because it omits index and replica overhead, it assumes the sample interval you were told rather than the one the system uses, and it ignores that aggregates, backups and non-numeric data are usually a larger share of the footprint than the raw readings. Size from a measured sample of real data rather than from a specification, calculate per retention tier rather than as one total, and present the result as a cost per year of retained history so the business can make the trade it is actually making.
1. The naive calculation and what it leaves out
The standard estimate is points, multiplied by samples per point per day, multiplied by bytes per sample, multiplied by days of retention. It is a reasonable first move and it is the right structure. The trouble is in every one of the four terms.
- Points is almost always understated. The number quoted is usually the count of points somebody cares about, not the count being collected. Collection is frequently configured at device or object level and sweeps up status, setpoint, mode and override objects alongside the measured values. A register built as described in the BMS point dictionary gives you the real number.
- Samples per day depends on the mechanism, not the intention. A point declared at fifteen minutes but collected by change-of-value can produce far more or far less, and a noisy analogue point on an unfiltered subscription can produce orders of magnitude more. The mechanics are in polling schedules and COV subscriptions.
- Bytes per sample is not the width of a float. A stored reading carries a timestamp, a point identifier, usually a quality flag, and whatever the storage engine adds per row or per block. Compression in a columnar or purpose-built store can pull this well below the uncompressed figure; a row-oriented relational table with a few indexes will push it well above.
- Retention is rarely one number. Most estates want recent data at full resolution and older data summarised, which makes the calculation a sum over tiers rather than a single product. That policy question is the subject of the data retention policy.
2. The overheads that dominate
| Contributor | Why it is missed | How to account for it |
|---|---|---|
| Indexes | Sizing is done on the data, and the index is treated as incidental | Measure it on a loaded sample. On a narrow table with several access paths it can rival the data itself |
| Replication and high availability | The estimate is for one copy because that is what the database holds | Multiply by the replica count before costing storage |
| Backups and their retention | A separate budget line nobody connects to the data volume | Size the backup chain explicitly, and test it, per backup and restore testing |
| Pre-computed aggregates | They are built to save query time, then forgotten as a footprint | Count every rollup you materialise; several resolutions can exceed the raw tier |
| Events, alarms and audit records | Not telemetry, so excluded from a telemetry estimate | Size separately. Alarm storms and the audit trail in the alert audit trail are bursty and verbose |
| Working space | Capacity is planned to the size of the data at rest | Leave headroom for compaction, index rebuilds, bulk loads and migrations |
Measure a week, then extrapolate
The single most useful thing you can do is load a representative week of real data into the store you intend to use, in the schema you intend to use, with the indexes you intend to create, and measure the result on disk. Divide by the period and you have a bytes-per-day figure that already includes compression, encoding, index and per-row overhead for your actual data, rather than a theoretical figure that includes none of them. Extrapolating a measurement carries far less error than compounding four estimates, and a week is long enough to capture the weekday and weekend duty cycles that change sample rates on change-of-value collection.
3. Sizing per tier rather than in total
Once the data is tiered, the calculation becomes a short table rather than one number, and the table is more useful than the number because it shows where the volume actually sits.
Work out, for each tier, the resolution held, the duration held, and the resulting volume. Almost always the full-resolution recent tier is a small fraction of the footprint and the long-tail summarised tier is most of it, which is the opposite of where attention naturally goes. That result is what makes the retention conversation tractable: an extra year of hourly summaries is usually cheap, an extra year of raw readings usually is not, and nobody can weigh those until they are costed separately. The resolution trade behind the tiers is covered in raw versus aggregated readings.
4. Planning for growth that is not linear
Volume grows for three reasons and only one of them is time.
- More sites. The most predictable driver and the easiest to plan, as long as the per-site figure is measured rather than assumed. Per-site volume varies enormously with plant type and controller generation.
- More points per site. Submetering programmes, additional sensors and newly integrated subsystems arrive continuously once a platform exists and is seen to work. This is the driver that most often breaks a capacity plan.
- Higher resolution. As soon as somebody tries to diagnose a short excursion they will ask for faster sampling on a subset of points, and a subset at a much faster interval can outweigh the entire original estate.
Plan the first explicitly, leave stated headroom for the second, and treat the third as a change with a cost attached rather than a configuration tweak. A multi-site estate also has to decide whether data is held centrally or per site before any of this can be totalled, which is a question of architecture rather than capacity and is covered in multi-site architecture.
5. Presenting the number so it survives contact with a budget
A single total in terabytes invites exactly one question, which is whether it can be smaller, and no useful discussion follows. Three presentations work better.
- Cost per year of retained history, per tier. This converts a technical estimate into the trade the business is actually making, and it is the form in which a retention decision can be taken.
- Cost per site per year. The unit that matters when the estate is growing, and the figure to put in a business case for the next site.
- The incremental cost of the next resolution step. Useful because it converts the recurring request for faster data into a priced option rather than an argument.
Each of those is derived from the same measured bytes-per-day figure, which is why getting that one number honestly is worth more than refining the rest of the model.
6. Missteps worth avoiding
- Sizing against the vendor's sample schema. Benchmark figures are produced on tuned configurations with minimal indexing and often without replicas. They are not wrong, they are just not your deployment.
- Letting compression ratios do the heavy lifting. Compression on building telemetry is genuinely good, because the data is slowly varying and highly repetitive. It is also highly dependent on the data and on the write pattern, and a ratio quoted from someone else's estate is not a plan.
- Forgetting the one-off loads. A history migration from an outgoing head end lands years of data at once, which is a peak rather than a trend. The practicalities are in migrating BMS point history.
- Treating storage as the only cost that scales. Query cost, backup windows, restore time and index maintenance all grow with volume, and a restore that no longer completes inside an acceptable window is a capacity problem even when the disk is cheap.
Limits
No bytes-per-sample figures, compression ratios or per-point volumes appear here, deliberately. They vary by storage engine, schema, index strategy and the character of the data by factors large enough that any number I published would mislead more often than it helped, and the whole argument above is that you should measure yours rather than borrow one. Nor is any particular storage technology recommended; the arithmetic is the same whichever you choose. This is written from the data and integration side rather than as controls engineering, and no claim is made here about equipment behaviour or sampling adequacy for any particular diagnostic purpose.
The idea to walk away with
Storage sizing for building telemetry fails on inputs, not on arithmetic. Four estimated terms compound into an answer with a wide error band, and the overheads that are left out of the model are frequently larger than the data that is in it.
Load a real week, measure what it occupies, extrapolate that, add the replica and backup multiples explicitly, and present the result as a cost per year of retained history per tier so the retention decision can be made by the people who will live with it.
Final thoughts
There is a quick check worth running on any existing deployment: take the current size on disk, divide by the number of days of data actually held, and compare that against whatever figure the project was sized on.
If the two are close, your model was sound and you can trust it for the next site. If they are far apart, you now know the direction of the error and can correct the plan before the next expansion rather than after it.
Disclosure
Alongside advisory work I also build a CMMS and CAFM platform, so I have a commercial interest in this category. Nothing above is a recommendation for it, and no vendor named here has paid for inclusion or had any editorial input. Weigh the analysis accordingly.
Sizing a building data platform?
Independent help measuring real volumes, building a tiered capacity model, and costing retention so the trade-off is visible before it is committed. 22+ years across CMMS, CAFM, EAM and ERP implementations.
Book a conversationRelated reading: BMS data retention policy, Raw versus aggregated readings, What is a BMS data historian, Migrating BMS point history, Backup and restore testing, BMS point dictionary.
Muhammad Abbas
CMMS / CAFM Manager & Independent Advisor · 22+ years across enterprise CMMS, EAM, CAFM and ERP implementations in utilities, oil and gas, manufacturing, government and facility operations.
Work with me