Home Alternatives Time-series basics Data Center & Infrastructure Telemetry Postgres basics Postgres guides Postgres best practices

Building Energy Management System: The Data Layer Behind Energy Monitoring, Sub-Metering, and M&V

Building Energy Management System (BEMS)

By Tiger Data Team

Updated at Sep 3, 2026

A single building's energy submeters look manageable. One meter at the main service entrance, maybe a handful more for major equipment. Then a portfolio team decides to submeter by floor. Then by tenant. Then, because a demand-charge tariff kicked in, by circuit. Multiply that hierarchy across a portfolio and layer a 15-minute interval requirement on top, and what looked like "a few more data points" is now a different data-modeling problem than storing building telemetry.

That's the building energy management system (BEMS) data problem, and it's a different problem than "where do we store BMS telemetry."

A building management system (BMS) operates equipment in real time: setpoints, schedules, alarms. A BEMS is specifically the energy-consumption and demand data layer, something EnergyCAP's own BEMS guide frames as collecting interval data from meters and submeters and turning it into trends, alerts, and savings verification. That data layer feeds both the BMS below it and the analytics layer above it. Related systems, not identical ones.

This piece assumes general BMS storage is already settled. If BACnet and Modbus protocol handling, the narrow-row schema, and hypertables aren't sorted out yet, start with the building management system database guide first. It also assumes portfolio-level energy benchmarking and anomaly detection are a separate concern, covered in Smart Building Analytics. What's left, and what this piece owns, is submetering's cardinality fan-out, demand monitoring as distinct from consumption rollups, and measurement and verification (M&V) as its own query pattern.

In short: a BEMS is the energy-specific data-capture layer sitting between BMS equipment telemetry and portfolio analytics. The database underneath it needs to do two things a general BMS schema doesn't: model a sub-meter hierarchy without exploding point count, and support M&V's baseline-and-adjust comparison alongside demand-specific peak queries. A building running one or two utility meters with no submetering program, demand-charge tariff, or M&V requirement doesn't need most of what follows. A single continuous aggregate, per the pillar, covers that case.

One more thing worth saying plainly: Tiger Data builds a Postgres-based time-series database, so this piece leans toward that answer. The goal here is an honest look at the data problem, not a sales pitch.

What a building energy management system actually monitors

Two signals drive everything a BEMS handles, and they're different in kind: consumption and demand.

Consumption is kWh, a rolled-up total over a period. Demand is kW, an instantaneous rate at a single point in time. A consumption query answers "how much energy did this building use in March." A demand query answers "what was the highest draw this meter recorded in any 15-minute window this month." Those are different questions, and as later sections show, they need different query shapes.

BEMS data itself usually comes from the same source a BMS already produces: utility-meter feeds and sub-meters, often BACnet- or Modbus-sourced energy points. This piece picks up downstream of that capture step. For the protocol-level detail on how those readings land in a database in the first place, the BMS page covers it.

From here, a BEMS data layer has three distinct jobs: model a sub-meter hierarchy without the point count becoming unmanageable, support demand-specific queries separate from consumption rollups, and support M&V's baseline-and-adjust computation. Three query problems over related data, each covered below.

Submetering: modeling the fan-out problem

One building-level meter becomes many once a portfolio submeters. A floor-level meter multiplies into per-tenant meters. Tenant meters can multiply again into per-circuit meters below that. Submetering isn't "more of the same point type" arriving at a higher rate. It's a hierarchy problem: a floor meter's readings relate to the tenant meters beneath it, and that parent-child relationship needs to be represented in the schema, not just tracked in a spreadsheet somewhere.

The fix is additive, not a redesign. The BMS pillar's narrow-row schema (time, a point identifier, value) already handles high-cardinality telemetry well. Extend it with a meter hierarchy: give each sub-meter its own identifier alongside a parent-meter reference.

ALTER TABLE energy_data
  ADD COLUMN meter_id text,
  ADD COLUMN parent_meter_id text;

A floor meter's row carries its own meter_id and a parent_meter_id pointing at the building-level meter. A tenant meter points at its floor. Rolling a tenant's usage up to its floor, or a floor's up to the building, becomes a join or recursive query against that hierarchy, rather than a manual reconciliation exercise.

There's a real regulatory driver behind why this is showing up now. ASHRAE 90.1-2022 requires metering devices that track electricity usage by load type in commercial buildings over 25,000 square feet in many jurisdictions, specifically at 15-minute intervals. That's not this piece's angle, but it's worth naming as context: interval-metering requirements are pushing more buildings into exactly the submetering fan-out described above.

The row-count math backs that up. A single building-level meter at hourly resolution produces a modest, easy-to-ignore number of rows per year. The same building with a meter hierarchy at 15-minute intervals, retained across a multi-year window, produces meaningfully more. That's the practical reason the fan-out matters for storage and retention planning, and it matters well before schema design.

Demand monitoring: peak demand, load curves, and alerting

Demand needs a different query shape than a consumption rollup, and the reason is financial as much as technical. Many commercial utility tariffs bill a demand charge based on the single highest interval of usage in a billing period. A building that stays well under its average consumption target but spikes once, briefly, to a high draw can still take a real hit on its bill for that one interval. Catching and managing that peak is a distinct, high-value query problem, separate from tracking total consumption.

That means the query isn't a sum over time_bucket. It's peak-window detection: finding the highest reading within a rolling window, fast enough to matter for alerting rather than only for month-end reporting.

The following is an illustrative pattern, not a drop-in production query, meant to show the shape of the problem:

SELECT
  meter_id,
  time,
  kw_reading,
  max(kw_reading) OVER (
    PARTITION BY meter_id
    ORDER BY time
    RANGE BETWEEN INTERVAL '1 hour' PRECEDING
      AND CURRENT ROW
  ) AS rolling_peak_kw
FROM demand_readings
WHERE time > now() - INTERVAL '7 days';

This is a rolling maximum over a bounded time window, grouped by meter. It's a different computation from the standard-deviation-based anomaly-detection pattern that Smart Building Analytics already covers for HVAC fault detection. Both are queries over related telemetry, but a demand-charge question and an equipment-anomaly question ask for different math.

Demand alerting, flagging a live interval reading as it approaches a known threshold, is a natural extension of this same query shape. It's worth a mention here rather than a section of its own: once a rolling-max query exists, comparing the latest value against a threshold and firing a notification is a small addition.

Measurement and verification (M&V): proving savings, not just monitoring usage

Monitoring answers "what's happening now." M&V answers a harder question: "what would have happened without this project." You can never directly meter the energy an efficiency retrofit stopped you from using. That's what a baseline comparison is for.

M&V, as defined by the International Performance Measurement and Verification Protocol (IPMVP), works by establishing a baseline period, adjusting that baseline for weather and occupancy differences, and then comparing actual post-intervention usage against the adjusted baseline. IPMVP is the industry standard for this practice.

The distinction from Smart Building Analytics' benchmarking is worth stating plainly, because both look like "compare energy data" on the surface. M&V compares a building against its own adjusted baseline over time, a before-and-after question. Portfolio benchmarking compares buildings against each other, or against a portfolio average, at a point in time, a peer-comparison question. Both are queries over energy data. They need different query shapes.

At a conceptual level, an M&V query needs three things from the database: the ability to compute a baseline from a defined historical window, the ability to apply an adjustment factor to that baseline, and the ability to compare the adjusted result against a later window. That's a comparison-across-time-ranges problem, closer to a windowed join than a single rollup.

WITH baseline AS (
  SELECT
    avg(kwh_reading) AS baseline_avg
  FROM energy_data
  WHERE time BETWEEN '2025-01-01' AND '2025-06-30'
),
adjusted AS (
  SELECT baseline_avg * 1.04 AS adjusted_baseline
  FROM baseline
),
post_period AS (
  SELECT avg(kwh_reading) AS actual_avg
  FROM energy_data
  WHERE time BETWEEN '2026-01-01' AND '2026-06-30'
)
SELECT
  adjusted.adjusted_baseline,
  post_period.actual_avg,
  adjusted.adjusted_baseline - post_period.actual_avg
    AS verified_savings
FROM adjusted, post_period;

That 1.04 adjustment factor is illustrative, standing in for whatever weather- or occupancy-normalization coefficient an M&V program actually calculates. The shape of the query, baseline window, adjustment, comparison window, is the point.

If there's one section in this piece that most directly answers "how do you store building energy data over time for verification, not just dashboards," this is it.

Migrating to a BEMS data layer: common starting points

Most teams arrive at this problem from one of four places.

From spreadsheets and manual utility-bill tracking. Energy data exists only as monthly totals pulled from a bill. The shift here is to an automated pipeline that captures interval-level meter data as it's generated, instead of a monthly number typed into a spreadsheet.

From a vendor BEMS dashboard with no queryable database underneath. The interval data exists, but it's locked inside a closed SaaS UI. The path forward is extracting or streaming that same meter data into a database the team controls, so custom M&V and demand queries become possible instead of whatever the vendor's dashboard happens to expose.

From a BMS that only stores equipment points today. No dedicated energy or meter schema exists yet. Adding the meter hierarchy described earlier is additive to existing BMS storage. It's not a second database and not a rip-and-replace migration.

From a single hourly continuous aggregate already in place. A team that followed the building management system database guide's basic example, or came from Smart Building Analytics' benchmarking layer, can add a meter-hierarchy dimension and a demand-specific rolling-window query without re-architecting ingestion. The continuous aggregate refresh policy that's already keeping that hourly rollup current keeps working the same way once the underlying table carries a meter hierarchy.

Each of these is a change from a specific starting point, not a repeat of the schema and query material already covered above.

Decision framework: do you need a dedicated BEMS data layer?

Not every building or portfolio needs submetering, demand monitoring, and M&V solved at the same time. Use this to identify which of these problems actually applies right now.

Extend your BMS schema with a meter hierarchy if:

You're moving from one utility meter to a handful of sub-meters, by floor, tenant, or circuit, and need to model that hierarchy, but don't yet need demand-charge alerting or savings verification.

Add demand monitoring if:

You're on a utility tariff with a demand charge, and peak kW during any interval materially affects your bill. You need peak-window and rolling-max queries, not just consumption sums.

Build an M&V layer if:

You're running, or verifying the results of, efficiency retrofits or capital projects and need to prove savings against an adjusted baseline. That's a different query shape than a monitoring rollup.

Use Smart Building Analytics' benchmarking layer instead if:

Your primary need is comparing buildings against each other or a portfolio average, or building anomaly-detection and KPI dashboards. That's the analytics layer covered in Smart Building Analytics, not the capture and verification layer covered here.

A single hourly continuous aggregate is probably still enough if:

You're managing one or two utility meters with no submetering program, no demand-charge tariff, and no M&V requirement today. Start there. The patterns in this piece are additive when you need them.

What this looks like in production

ApexAnalytica, an AI-powered building intelligence platform, states that it targets IPMVP-compliant measurement and verification. The platform runs on an energy_data hypertable and an energy_hourly materialized view, the same underlying substrate referenced from a storage angle in the BMS guide and from an anomaly-detection angle in Smart Building Analytics. This piece's M&V and demand-monitoring patterns are the kind of query that substrate is built to support.

The real-world context matters for the submetering framing covered earlier: the platform serves buildings across care and social housing, hospitality, leisure, retail, commercial offices, veterinary, and energy-sector sites, genuine portfolio-scale variety, not a single building's worth of data.

Use cases to explore further are Soundsensing, which applies interval-data patterns to HVAC predictive maintenance, and Palas, which applies such patterns to air-quality sensor monitoring.

For general BMS storage and schema foundation, BACnet and Modbus protocol handling, and the narrow-row schema this piece extends, start with the building management system database guide.

For portfolio energy benchmarking, anomaly detection, and KPI dashboards built on top of the same underlying data, see Smart Building Analytics.

For the same interval-data patterns applied at the grid and utility scale rather than the building scale, see Postgres for Energy & Utilities and IoT energy data at scale.

For the same high-cardinality, interval-data pattern applied to different infrastructure verticals, see Water Utilities Database and Fleet Telemetry Database.

FAQ

What's the difference between a BMS and a BEMS?

A BMS, or BAS, operates building equipment in real time: setpoints, schedules, alarms. A BEMS is specifically the energy-consumption and demand data and reporting layer, often fed by the same points a BMS produces. They're related systems, not identical ones.

What database should a building energy management system (BEMS) use to store sub-metered energy and demand data over time?

A time-series-optimized database that can model a sub-meter hierarchy without exploding point count, support both consumption rollups and demand-specific peak queries, and run M&V baseline comparisons, without a separate system for each. What matters specifically: interval-data ingestion rate, hierarchical modeling, and flexible time-range comparisons.

What is measurement and verification (M&V) in building energy management?

M&V is a baseline-and-adjust methodology, aligned with IPMVP: establish a baseline, adjust it for weather and occupancy differences, then compare actual post-change usage against that adjusted baseline to prove savings.

How does submetering work, and why does it multiply my data volume?

Submetering adds meters below the building-level meter, by floor, tenant, or circuit. That's a hierarchy and cardinality problem. One meter becomes many, not just additional rows of the same point type.

How much interval data does a building submetering program actually generate?

Interval readings, commonly at 15-minute resolution per ASHRAE 90.1-2022 requirements for larger commercial buildings, multiplied across a meter hierarchy and retained over months or years, add up quickly. Row-count and retention planning matter well before volume becomes unmanageable.

Can I run M&V calculations directly against the same database that stores my BMS telemetry?

Yes. M&V's baseline-and-adjust comparison and demand-monitoring's rolling-window queries can run on the same Postgres or TimescaleDB instance that stores raw BMS telemetry and sub-meter readings, without a second system.

What's the difference between energy monitoring and M&V?

Monitoring is a live rollup of what's happening now, a dashboard question. M&V is a baseline-and-adjust comparison proving what would have happened without an intervention, a verification question. Different query shapes over related data.

Is submetering the same as just adding more sensor points?

No. It looks similar on the surface, but submetering specifically means modeling a parent-child meter hierarchy, not simply widening a table or adding an arbitrary new point type.

How does demand monitoring differ from tracking energy consumption?

Consumption is a rolled-up total over time, measured in kWh. Demand is an instantaneous rate at a point in time, measured in kW. Many utility tariffs bill based on peak demand specifically, which is why it needs its own query pattern, rolling peak detection, rather than a consumption sum.

Do I need a separate database for energy data, or can it live alongside my BMS and analytics data?

No. Submetering, demand monitoring, and M&V queries can run against the same Postgres or TimescaleDB instance already storing BMS telemetry and powering the analytics layer, without standing up a separate system.

What is IPMVP, and why does it matter for M&V?

IPMVP is the International Performance Measurement and Verification Protocol, the industry-standard framework for M&V methodology. It's referenced by name here so the underlying standard can be checked directly, rather than taken on a vendor's word.

What's the ROI of a BEMS?

Energy-savings and payback claims for BEMS implementations vary by source, building type, and program scope, and any specific figure deserves a skeptical read of its source before it's used to justify a project. What's often under-counted: avoided demand charges and verified savings through M&V are separate components of ROI beyond raw consumption reduction, and both are easy to leave out of a back-of-envelope estimate.

Building Energy Management System: The Data Layer Behind Energy Monitoring, Sub-Metering, and M&V

By Tiger Data Team

Updated at Sep 3, 2026

That's the building energy management system (BEMS) data problem, and it's a different problem than "where do we store BMS telemetry."

What a building energy management system actually monitors

Two signals drive everything a BEMS handles, and they're different in kind: consumption and demand.

Submetering: modeling the fan-out problem

ALTER TABLE energy_data
  ADD COLUMN meter_id text,
  ADD COLUMN parent_meter_id text;

Demand monitoring: peak demand, load curves, and alerting

The following is an illustrative pattern, not a drop-in production query, meant to show the shape of the problem:

SELECT
  meter_id,
  time,
  kw_reading,
  max(kw_reading) OVER (
    PARTITION BY meter_id
    ORDER BY time
    RANGE BETWEEN INTERVAL '1 hour' PRECEDING
      AND CURRENT ROW
  ) AS rolling_peak_kw
FROM demand_readings
WHERE time > now() - INTERVAL '7 days';

Measurement and verification (M&V): proving savings, not just monitoring usage

WITH baseline AS (
  SELECT
    avg(kwh_reading) AS baseline_avg
  FROM energy_data
  WHERE time BETWEEN '2025-01-01' AND '2025-06-30'
),
adjusted AS (
  SELECT baseline_avg * 1.04 AS adjusted_baseline
  FROM baseline
),
post_period AS (
  SELECT avg(kwh_reading) AS actual_avg
  FROM energy_data
  WHERE time BETWEEN '2026-01-01' AND '2026-06-30'
)
SELECT
  adjusted.adjusted_baseline,
  post_period.actual_avg,
  adjusted.adjusted_baseline - post_period.actual_avg
    AS verified_savings
FROM adjusted, post_period;

If there's one section in this piece that most directly answers "how do you store building energy data over time for verification, not just dashboards," this is it.

Migrating to a BEMS data layer: common starting points

Most teams arrive at this problem from one of four places.

Each of these is a change from a specific starting point, not a repeat of the schema and query material already covered above.

Decision framework: do you need a dedicated BEMS data layer?

Not every building or portfolio needs submetering, demand monitoring, and M&V solved at the same time. Use this to identify which of these problems actually applies right now.

Extend your BMS schema with a meter hierarchy if:

You're moving from one utility meter to a handful of sub-meters, by floor, tenant, or circuit, and need to model that hierarchy, but don't yet need demand-charge alerting or savings verification.

Add demand monitoring if:

You're on a utility tariff with a demand charge, and peak kW during any interval materially affects your bill. You need peak-window and rolling-max queries, not just consumption sums.

Build an M&V layer if:

You're running, or verifying the results of, efficiency retrofits or capital projects and need to prove savings against an adjusted baseline. That's a different query shape than a monitoring rollup.

Use Smart Building Analytics' benchmarking layer instead if:

A single hourly continuous aggregate is probably still enough if:

You're managing one or two utility meters with no submetering program, no demand-charge tariff, and no M&V requirement today. Start there. The patterns in this piece are additive when you need them.

What this looks like in production

Use cases to explore further are Soundsensing, which applies interval-data patterns to HVAC predictive maintenance, and Palas, which applies such patterns to air-quality sensor monitoring.

For general BMS storage and schema foundation, BACnet and Modbus protocol handling, and the narrow-row schema this piece extends, start with the building management system database guide.

For portfolio energy benchmarking, anomaly detection, and KPI dashboards built on top of the same underlying data, see Smart Building Analytics.

For the same interval-data patterns applied at the grid and utility scale rather than the building scale, see Postgres for Energy & Utilities and IoT energy data at scale.

For the same high-cardinality, interval-data pattern applied to different infrastructure verticals, see Water Utilities Database and Fleet Telemetry Database.

FAQ

What's the difference between a BMS and a BEMS?

What database should a building energy management system (BEMS) use to store sub-metered energy and demand data over time?

What is measurement and verification (M&V) in building energy management?

How does submetering work, and why does it multiply my data volume?

How much interval data does a building submetering program actually generate?

Can I run M&V calculations directly against the same database that stores my BMS telemetry?

What's the difference between energy monitoring and M&V?

Is submetering the same as just adding more sensor points?

No. It looks similar on the surface, but submetering specifically means modeling a parent-child meter hierarchy, not simply widening a table or adding an arbitrary new point type.

How does demand monitoring differ from tracking energy consumption?

Do I need a separate database for energy data, or can it live alongside my BMS and analytics data?

What is IPMVP, and why does it matter for M&V?

What's the ROI of a BEMS?

Building Energy Management System: The Data Layer Behind Energy Monitoring, Sub-Metering, and M&V

What a building energy management system actually monitors

Submetering: modeling the fan-out problem

Demand monitoring: peak demand, load curves, and alerting

Measurement and verification (M&V): proving savings, not just monitoring usage

Migrating to a BEMS data layer: common starting points

Decision framework: do you need a dedicated BEMS data layer?

Extend your BMS schema with a meter hierarchy if:

Add demand monitoring if:

Build an M&V layer if:

Use Smart Building Analytics' benchmarking layer instead if:

A single hourly continuous aggregate is probably still enough if:

What this looks like in production

Related resources

FAQ

Building Energy Management System: The Data Layer Behind Energy Monitoring, Sub-Metering, and M&V

What a building energy management system actually monitors

Submetering: modeling the fan-out problem

Demand monitoring: peak demand, load curves, and alerting

Measurement and verification (M&V): proving savings, not just monitoring usage

Migrating to a BEMS data layer: common starting points

Decision framework: do you need a dedicated BEMS data layer?

Extend your BMS schema with a meter hierarchy if:

Add demand monitoring if:

Build an M&V layer if:

Use Smart Building Analytics' benchmarking layer instead if:

A single hourly continuous aggregate is probably still enough if:

What this looks like in production

Related resources

FAQ