What Is a BMS Data Historian?

The question usually arrives in a budget conversation. Somebody wants to do energy analysis or fault detection, discovers the data only goes back ninety days, and is told they need a historian. What a historian actually is, whether this estate needs one, and what it would cost to run are rarely explained, and the term gets used for everything from a purpose-built industrial product to a folder of exported spreadsheets.

The message up front: a historian is a time-series database plus the operational machinery around it, optimised for very high write rates of timestamped values and for range queries over them. The reason to want one is rarely raw capability; it is independence. Your history outlives your head end, your controllers and your contractors, and keeping it in any of those means losing it when they change. If you only need ninety days of operational lookback, the platform you already own is probably adequate and a historian is an unnecessary cost.

1. What it is

At its core a historian answers one shape of question: what was the value of these points between these two times. Everything about its design follows from doing that at scale.

A building generating readings from a few thousand points at modest intervals produces a continuous stream of small, highly similar records, appended in roughly time order, never updated, and read back in ranges rather than individually. That workload is unlike the one a conventional business database is built for, and the differences are structural rather than a matter of tuning.

The term covers a spectrum. At one end are long-established industrial historians from the process control world, with heavy operational tooling. At the other are modern open-source time-series databases that provide the storage engine and leave the rest to you. Both are legitimately called historians and they are very different purchases.

2. What a historian is not

• Not a replacement for the controllers. It stores what happened. It does not control anything, and nothing should depend on it to run.
• Not an analytics product. It holds the data and answers range queries. Fault detection, energy analysis and reporting sit above it, which is the distinction drawn in from BMS to building analytics.
• Not a source of meaning. It stores tags and values. It does not know that tag 4471 is the supply air temperature of an air handling unit serving the third floor. That knowledge lives elsewhere, which is section 5.
• Not automatically a system of record. It becomes one only if you decide it is, document that, and stop relying on the copies elsewhere.

3. Why not just use the head end's database

Often you can, and for a single building with modest ambitions you probably should. The arguments for separating are not about capability on day one.

• Lifecycle mismatch. Head ends are replaced considerably more often than buildings are. History held inside one becomes a migration problem every time, and in practice is usually abandoned rather than migrated. The scale of that is in migrating BMS point history when replacing a head end.
• Commercial position. Data inside a supplier's platform is data whose accessibility depends on your relationship with that supplier, which is one of the lock-in mechanisms discussed in BMS service contracts.
• Multi-vendor estates. Two head ends means two histories with two schemas. One historian above them gives one place to ask portfolio questions.
• Query load. Running heavy analysis against the database that also serves the operator interface is a way to make the operator interface slow at exactly the wrong moment.
• Retention control. You set the policy rather than inheriting the platform's default, which is the problem described in the retention policy article.

None of these matters much in year one. All of them matter by year five, which is the honest framing for the business case.

4. When it is justified, and when it is not

Reasonable triggers:

• More than one head end or manufacturer, and a requirement to compare across them.
• Analysis needing more than a year of history, because seasonal comparison needs like for like.
• A head end replacement on the horizon, where separating the history first turns a migration into a non-event.
• Fault detection or energy analytics that will run continuous queries you do not want hitting the operational platform.
• A reporting or compliance obligation requiring data to outlive any one system.

Reasons that are usually not sufficient on their own: wanting prettier charts, which is a visualisation problem; running out of space, which is a retention policy problem; and a supplier recommending one, which is worth examining against the list above before accepting.

5. The part people forget: a historian stores tags, not assets

This is the most consequential gap in most implementations. A historian will happily store several thousand series keyed by whatever identifier the collector supplied, and it has no idea what any of them represent.

Without a metadata layer you can answer "what was tag 4471 doing on Tuesday" and not "what was the supply air temperature on the third floor", which is the question anyone actually has. Worse, a query for all supply air temperatures across the estate is impossible without somewhere to record which tags those are.

So a historian project is really two projects: the store, and the metadata that makes it interpretable. That metadata is the point-to-asset relationship covered in BMS point-to-asset mapping and the point register covered in the BMS point dictionary. Budgeting for the first and not the second produces a well-populated store nobody can query usefully, which is a common and expensive outcome.

6. Sizing it, and what running it involves

Volume is driven by point count, sampling frequency, retention per tier and how compressible the data is, and the arithmetic is set out in sizing a process historian. Two things are worth saying here because they are consistently underestimated.

First, the raw volume is usually smaller than people fear once compression and tiering are applied, and the resolution-versus-duration decisions matter far more than the headline point count.

Second, the ongoing operational burden is usually larger than people expect, and it is where historian projects actually fail. Somebody has to own backups and prove that restores work, monitor ingestion for gaps, apply retention and verify that it executed, manage access, patch it, and keep the metadata current as the estate changes. That is a recurring commitment rather than a project task, and a historian without an owner degrades into a store of data nobody trusts within a couple of years.

7. What to establish before buying one

• How data gets in from each of your systems, and whether that path survives a head end change. Collection mechanisms in BACnet data logging.
• How data gets out: a documented query interface, and a bulk export in an open format. Test the export before purchase, not after.
• Whether late and out-of-order writes are accepted, because buffered recovery depends on it.
• How retention and downsampling are configured, and whether rollup rules can differ by point type, since counters and averages need different treatment.
• Where the metadata will live and how it joins to the series.
• Licensing shape: per tag, per server, per volume or subscription. On a growing estate these diverge sharply.
• Who will run it, named, with time allocated. The question that most often has no answer.

The idea to walk away with

A historian is a time-series store with the operational machinery to keep it honest, and the reason to want one is that your building history should outlive the software that happened to be collecting it. That is an independence argument, not a capability argument, and it is why the question is usually answered by thinking about your next head end replacement rather than about storage.

If you do build one, budget for the metadata and the owner alongside the store. A historian without either is a large quantity of numbers that nobody can interpret and nobody is maintaining.

Final thoughts

Before specifying anything, answer one question with evidence rather than assumption: how far back does your building data actually go, in each system that holds it. The answer is frequently shorter than people believe, and occasionally the data already exists in a forgotten copy somewhere.

That single finding tends to settle the argument either way, and it costs an afternoon rather than a procurement.

Related reading: BMS trend logs vs external historians, Sizing a process historian, BACnet data logging, BMS data retention policy, BMS point-to-asset mapping, SCADA and historian integration.