---
title: "Building Management System Database"
description: "How to architect a database for BMS, BACnet, and Modbus sensor data: schema design, time-series patterns, and a real production case study. "
section: "Postgres for IoT"
---
> **TimescaleDB is now Tiger Data.**
A single point on a building management system, an HVAC setpoint, an occupancy sensor, an energy submeter, refreshes every 15 to 60 seconds. Multiply that across every floor in a building, then across every building in a portfolio, and the row count stops being an abstraction. One developer building an AI-powered facility platform watched a 12-month hourly heat map query cross six seconds on vanilla Postgres, the point where users assume the dashboard is broken, before moving the workload onto a purpose-built time-series backend and getting the same query under a second. The full story shows up later in this piece.
First, a disclosure: Tiger Data builds a [Postgres-based time-series database](https://www.tigerdata.com/timescaledb), so this piece leans toward that answer. The goal here is still an honest, engineering-first one, including the parts of a BMS deployment where a dedicated database isn't the immediate bottleneck.
Building management system (BMS), building automation system (BAS), and building automation and control system (BACS) all describe the same thing: the centralized system that monitors and controls a building's HVAC, lighting, energy, and life-safety equipment. Every major explainer on this topic uses the three terms interchangeably, and this one will too.
This page covers, in order: what a BMS produces and why that data behaves like a time-series workload, how to model it in a schema, what a real production deployment looks like end to end, what shouldn't go into this kind of database, and how a semantic metadata layer fits alongside it.
## What database should a building management system use?
A relational, SQL-queryable time-series database, such as PostgreSQL extended with TimescaleDB, self-hosted or run as a managed service on Tiger Cloud, handles high-frequency BMS telemetry well. It supports both time-bucketed rollups for dashboards and reports, and SQL joins against asset, tenant, and maintenance metadata, which many purpose-built time-series-only databases don't support natively. For a single building running short-term trends and alarms, a BMS's own native historian is often enough. The decision framework below covers both cases.
## What is a building management system, and what data does it produce?
A building management system monitors and controls the physical systems inside a building, most commonly HVAC, lighting, energy metering, indoor air quality (IAQ), and life-safety equipment, through a network of sensors, controllers, and actuators. Sensors read the physical world (temperature, occupancy, CO2, power draw). Controllers evaluate that reading against a setpoint or a rule. Actuators (dampers, valves, relays) act on the result. That sensors-to-controllers-to-actuators model is the shared vocabulary across virtually every BMS explainer, and it pays to keep in mind from the start, because every data-modeling decision later in this piece traces back to it.
What comes out of that pipeline is a wide mix of point types: HVAC setpoints and running status, occupancy sensor states, lighting on/off and dimming levels, energy submeter readings, IAQ sensor values (CO2, particulate matter, humidity), and fault or alarm events. A single mid-size commercial building can easily expose several thousand distinct points, each refreshing on its own interval, independent of the others. That's what turns "a database for one building" into "a database for a portfolio": the row count doesn't just scale with building count, it scales with point count per building times refresh frequency times building count.
Most real BMS installations don't run a single protocol. They run at least two, bridged together.
### BACnet vs. Modbus: the two protocols behind most BMS data
BACnet (Building Automation and Control Network) is purpose-built for building automation, with a richer object model designed to describe HVAC equipment, schedules, and alarms natively. It's commonly found at the management and supervisory layer, the tier that talks to the BMS software itself.
Modbus is older, simpler, and originally built for industrial control generally, not buildings specifically. It's widely supported at the device and field layer, the tier closest to individual sensors and actuators, because nearly every controller and meter manufacturer implements it.
The common pattern is that a building's supervisory layer speaks BACnet while its field devices speak Modbus, with a gateway or an integration platform bridging the two. Tridium Niagara is the platform most widely deployed for exactly this job: it ingests BACnet, Modbus, and other building protocols and normalizes them into a single point database that the rest of the BMS software reads from. You don't need controls-engineer depth on either protocol to follow the rest of this piece, just enough shared vocabulary to know that decoded BACnet and Modbus data both arrive, eventually, as timestamped values with a point name attached.
## Why BMS telemetry is a time-series workload
Run the row-rate math for a single portfolio. A building with 2,000 points, each refreshing every 30 seconds, produces roughly 5.7 million readings a day. Across a 10-building portfolio, that's 57 million rows a day, and the number only grows as more buildings, more points, or tighter refresh intervals get added. That math is what separates a BMS's own reporting screen, built for one building's current state, from the kind of cross-portfolio analytics a facilities team eventually wants to run.
The characteristics underneath that math are the same ones that define any time-series workload: writes are append-only (a new reading arrives, it doesn't overwrite the last one), rows are strictly timestamp-ordered, and the combination of building ID and point name creates high cardinality, meaning a very large number of distinct series to track independently. A 10-building portfolio with 2,000 points each amounts to 20,000 distinct series, each with its own history, and a schema that treats them as one undifferentiated blob of readings makes even a simple per-building query expensive.
The obvious objection: doesn't the BMS already have a historian built in? Yes, and it's usually good at what it's built for. Most BAS platforms ship a native historian that handles single-building configuration, trend logs, and alarms well. Where that breaks down is exactly where a portfolio operator eventually needs to go: cross-portfolio SQL analytics that compare buildings side by side, multi-year retention for compliance and benchmarking, and running an AI or analytics layer against the same data the historian is collecting, without exporting it somewhere else first. Closing precisely that gap is the story behind the production deployment covered later in this piece.
## Schema design for BMS and sensor data
The starting schema for BMS telemetry is a narrow table: one row per reading, with columns for time, building ID, point name, and value. That's a deliberate choice over the alternative, a wide table with one column per point, for reasons that hold at scale: points get added and removed constantly as equipment changes, and a narrow schema absorbs that without a schema migration; queries stay simple because they filter and aggregate rather than reference dozens of named columns; and columnar compression (covered below) works far better against a narrow, repetitive row shape than a sparse wide one.
A representative table and its [hypertable](https://www.tigerdata.com/docs/reference/timescaledb/hypertables) declaration:
`CREATE TABLE bms_points (
time TIMESTAMPTZ NOT NULL,
building_id TEXT NOT NULL,
point_name TEXT NOT NULL,
value DOUBLE PRECISION NOT NULL,
protocol TEXT,
unit TEXT
);
SELECT create_hypertable('bms_points', by_range('time'));`
`create_hypertable()` partitions `bms_points` by time so that queries against a recent window, which is most BMS queries, stay bounded instead of scanning the entire table's history.
Raw readings answer "what was this point's value at this moment," but most BMS reporting questions are shaped differently: "what did this building's energy consumption look like, hour by hour, over the last year." Scanning millions of raw rows to answer that on every dashboard load doesn't hold up. A [continuous aggregate](https://www.tigerdata.com/docs/learn/continuous-aggregates), a materialized view that TimescaleDB refreshes incrementally in the background, solves it by keeping a pre-computed rollup in sync as new data arrives:
`CREATE MATERIALIZED VIEW bms_hourly
WITH (timescaledb.continuous) AS
SELECT
time_bucket('1 hour', time) AS hour,
building_id,
point_name,
avg(value) AS avg_value,
max(value) AS max_value
FROM bms_points
GROUP BY hour, building_id, point_name;`
A dashboard querying a year of hourly data reads pre-computed buckets from `bms_hourly` instead of re-scanning raw readings, which is what turns a multi-second query into a sub-second one. This is the same mechanism behind the real production result covered in the next section.
Compression is a separate concern from live ingest and should be treated that way. Recent data, still being actively written and queried at fine granularity, stays in row format. Older chunks, once they're no longer being written to, convert to columnar storage through [hypercore](https://www.tigerdata.com/docs/reference/timescaledb/hypercore), TimescaleDB's hybrid row-columnar storage engine, which reduces their footprint substantially and speeds up analytical scans across them. The exact ratio depends on the data's shape, so treat any specific compression figure as workload-dependent rather than a fixed guarantee, but the pattern itself, row storage for hot data and columnar storage for cold data, is what makes multi-year retention economically realistic for a growing portfolio.
## The real-world pattern: BACnet, Niagara, and Modbus data landing in Postgres
[ApexAnalytica](https://www.tigerdata.com/blog/how-apexanalytica-runs-building-telemetry-transactional-data-rag-on-single-postgres-instance) is an AI-powered building intelligence platform built by a single developer with 25 years of building automation experience. It connects to BMS systems over BACnet, Tridium Niagara, Modbus TCP, MQTT, REST, and SQL Server, ingesting between 1,000 and 10,000 data points per second. Six clients are live today across 38 sites spanning care and social housing, hospitality, leisure, retail, commercial offices, veterinary practices, and energy-sector buildings, with a 1,700-property care and social housing estate in the deployment pipeline.
The schema underneath it is close to the narrow-row pattern above: an `energy_data` hypertable using a 30-day chunk interval, currently holding 1.32 million rows. An `energy_hourly` materialized view, built on `time_bucket('1 hour', ...)` and refreshed on a schedule, is what took the platform's 12-month hourly heat map query, the one rendering a full year of consumption patterns per building in a single visual, from over six seconds on vanilla Postgres to under a second. Six seconds is roughly the point where a user assumes the dashboard has broken; under a second means an operator can actually explore the data interactively.
ApexAnalytica also runs pgvector in the same Postgres instance to power a retrieval-augmented-generation AI agent, called Ask Apex, that reasons over building documentation alongside live telemetry. Telemetry, transactional building metadata, and an AI layer's vector embeddings all live in one database, with one backup and one security boundary to manage, rather than three separate systems that need to stay in sync.
Decoding BMS protocol data into a purpose-built time-series store has real precedent beyond this piece: an "InfluxDB Driver for Tridium Niagara N4" is currently listed on the Niagara Marketplace, letting Niagara-based BMS installations export historian data directly into InfluxDB for downstream querying and visualization. It's a genuine point of comparison rather than a competitive dig, since it confirms that the underlying architecture question this piece is answering (decode the protocol layer, land the result in a purpose-built store) is one the market has already validated.
Where the comparison matters is the point ApexAnalytica's own use case sits squarely on: cross-building portfolio queries that join telemetry against asset or tenant metadata. InfluxDB's own community forum has documented that SQL joins aren't available across InfluxDB measurements, a real and attributed constraint (see [what InfluxDB got wrong](https://www.tigerdata.com/blog/what-influxdb-got-wrong) for the fuller pattern) that becomes more visible the more a portfolio's reporting depends on relating telemetry to the rest of its operational data, rather than querying telemetry in isolation.
A second, smaller-scale proof point of the same underlying pattern: [Palas](https://www.tigerdata.com/case-studies/palas), a German manufacturer of air-quality measurement devices used in smart-city and environmental-monitoring deployments, runs on TimescaleDB with roughly 4x data compression (a 200GB dataset shrank to 55GB) and an average complex-query time of about 25 milliseconds, on modest hardware (2 CPUs, 4GB of RAM). [Soundsensing](https://www.tigerdata.com/case-studies/soundsensing), which runs AI-driven predictive maintenance for HVAC units in commercial real estate, saw historical queries run up to 20 times faster after moving off a struggling PostgreSQL setup, and scaled to 10 times the sensor count without a re-architecture. Different scale, same underlying shape: decoded sensor data landing in a schema built for it.
## What not to store in Postgres
Not every point in a BMS deployment is a strong fit, so this section is specific rather than hand-wavy about where the line sits. Raw, per-fixture lighting or device-level state changes at sub-second frequency can stretch a general-purpose time-series layer, especially once a portfolio scales into thousands of fixtures each generating its own high-frequency stream.
This is a forward-looking constraint: ApexAnalytica itself has flagged it, and as the platform's roadmap moves toward ingesting per-fixture lighting data, the team is actively evaluating continuous aggregates (to replace a custom materialized-view refresh service with incremental refresh policies) and columnar compression on cold chunks, specifically because that lighting workload is expected to push the current architecture harder than anything it's handling today.
The rule of thumb: if a point updates on a human-relevant timescale, seconds to minutes, it's a strong fit for this kind of database as-is. If a point updates faster than that, and at very high fixture or device counts, evaluate a compression and rollup strategy up front rather than assuming a plain drop-in will hold at scale.
## A note on semantic metadata: Brick Schema and Project Haystack
The building-automation industry is actively working on open semantic tagging standards, Brick Schema and Project Haystack chief among them, as a way to describe what a building's data points actually mean: that a given point is a supply-air temperature sensor on a specific air handler serving a specific floor, not just a bare numeric value with a name.
A time-series database and a semantic metadata layer solve different problems, and they're complementary rather than competing. The database stores and queries the readings efficiently at scale. The semantic layer describes what those readings represent and how they relate to physical assets, so that software, and increasingly AI tools, can reason about a building's layout without a person manually mapping every point by hand. A team building a serious BMS data platform, particularly one that pulls from multiple BMS vendors or protocols, will likely want both rather than treating one as a substitute for the other.
## Decision framework: do you need a dedicated database for your BMS data?
Think of this as a practical self-assessment rather than a sales pitch. Most teams fall clearly into one bucket once they read through the criteria below.
**Choose a dedicated time-series database (such as Postgres with TimescaleDB) if:**
- You operate more than one building or site and need to run analytics, reporting, or AI/ML across the portfolio, not just within a single BAS
- You need retention beyond what your BAS's native historian is designed for, multi-year trend analysis, compliance reporting, or benchmarking
- You need to join telemetry against relational data, tenant, lease, asset, or maintenance records, in the same queries, which is awkward or unsupported in many purpose-built time-series-only stores
- You want to run other workloads, a RAG or AI layer, transactional application data, against the same data without maintaining a separate database
**Your BAS's native historian is probably enough if:**
- You're managing a single building or a small handful of sites with no cross-portfolio reporting requirement
- Your needs are limited to short-to-medium-term trend logs, alarms, and basic dashboards that your existing BAS platform already provides
**Consider adding a semantic metadata layer (Brick Schema or Project Haystack) alongside your database if:**
- You're integrating data from many different BMS vendors or protocols and need a standardized way to describe what each point means across buildings
- You're building AI tooling that needs to reason about building layout and asset relationships, not just query raw values
## Migrating to a Postgres-based BMS database
Most teams evaluating this architecture aren't starting from a blank slate. They're migrating from one of a few common starting points.
**From a BAS-native historian.** The typical pattern is standing up a parallel ingestion pipeline, often through the same gateway or Niagara-style bridge already pulling BACnet and Modbus data, that writes into the new database alongside the existing historian. Both systems run in parallel through a validation period, and dashboards and reports migrate over once the new pipeline is trusted.
**From an existing InfluxDB or other time-series-only deployment.** This is a validated, already-in-market pattern, the same Niagara-to-InfluxDB integration referenced earlier confirms that decoded BMS protocol data is portable to whatever backend receives it. The migration is primarily about re-pointing that same decoded data at a new backend, which is a reasonable path for a team that has hit the join or relational limitation discussed above.
**From spreadsheets or ad hoc CSV exports.** Common for smaller portfolios that haven't needed a dedicated database yet, and often the sign that manual review of exported trend logs has stopped scaling with the number of buildings someone is tracking by hand. The first step is the same narrow-row schema covered earlier, followed by backfilling historical exports before wiring up live ingestion. Once live ingestion is running, the export-and-review cycle that used to happen monthly or quarterly becomes a query that runs on demand.
Connecting an existing MQTT-based ingestion pipeline to Postgres is a well-documented pattern in its own right, since many BMS gateways and integration platforms publish decoded points over MQTT before they land in a central database. See the [MQTT to PostgreSQL guide](https://www.tigerdata.com/learn/mqtt-to-postgresql) for the implementation-level detail. For BMS gateways or controllers that need to buffer point data locally before syncing centrally, the article [What Is an Edge Database?](https://www.tigerdata.com/learn/edge-database) covers that pattern directly.
## Where this fits
This same underlying architecture pattern, decoding a domain-specific protocol into a narrow-row time-series schema, isn't unique to buildings. The [water utilities database guide](https://www.tigerdata.com/learn/water-utilities-database-how-to-store-query-scada-ami-quality-data-at-scale) applies it to SCADA and AMI sensor data at multi-site scale, which is useful reading if you're evaluating whether this approach generalizes beyond a single infrastructure vertical.
For deeper background on when a legacy historian is or isn't enough, the fuller argument behind the "your BAS already has a historian" section above is covered in [Data Historian vs. Time-Series Database](https://www.tigerdata.com/learn/moving-past-legacy-systems-data-historian-vs-time-series-database) and [What Is a Data Historian?](https://www.tigerdata.com/learn/what-is-a-data-historian). For a broader industrial-IoT requirements framing that complements this piece's building-specific focus, see the [IIoT database requirements checklist](https://www.tigerdata.com/learn/iiot-database-requirements).
Dedicated companion pieces on smart building analytics and building energy management system databases are planned as follow-ups to this page, going deeper into portfolio-level analytics and energy-specific reporting than this guide's scope covers.