---
title: "The Data Layer for the AI Data Center"
published: 2026-07-08T09:47:46.000-04:00
updated: 2026-07-08T09:50:54.000-04:00
excerpt: "A TimescaleDB technical reference architecture for operational time-series data across AI data centers, from control layer to enterprise rollup."
tags: AI
authors: Hien Phan, Noah Hein, Matty Stratton, Nate O'Farrell
---

> **TimescaleDB is now Tiger Data.**

_This is Part II of a two-part series on the AI data center stack. Part I,_ [_AI's Physical Constraints: How AI Rewired the Data Center_](https://www.tigerdata.com/blog/how-ai-rewired-the-data-center)_, explains why AI capacity has become constrained by the physical data center stack: accelerators, memory, cooling, power, time, and water._

## Physical Plant Telemetry Is Now a Data-Layer Requirement

In an AI data center, the workload no longer stops at the server boundary. A synchronized training job can move power, cooling, battery response, and power electronics in patterns that look less like conventional facility load and more like part of the compute system itself. The physical plant has become coupled to the computer's execution profile.

This paper starts from the operational consequence: once those systems are coupled, their telemetry has to be correlated, retained, and queried together.

That coupling changes what operational telemetry has to do.

The plant is still operated through established OT patterns: PLCs, protection systems, BMS, PMS, CDU controllers, SCADA, message brokers, and layered networks. None of that goes away. What changes is the correlation requirement. Operators now need to ask questions that cross systems and timescales: what happened to facility load during a training phase transition, which cooling loop reacted first, which racks drove the phase imbalance, whether battery or UPS behavior aligned with GPU power movement, and how a hall-level event propagated into the campus electrical posture.

Those are not dashboard-only questions. They are data-layer questions. The system has to ingest the raw signal, preserve its context, retain it long enough to matter, and make it queryable without moving the data out of the environment where operations run.

The volume is assumed. NVIDIA DCGM exposes GPU telemetry through [field identifiers](https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-api/dcgm-api-field-ids.html) and exporter paths covering clocks, power, thermals, energy, and fabric health, with third-party collector coverage describing thousands of metrics across GPU, MIG, NVLink, NVSwitch, and CPU scopes. The facility side adds liquid-cooling loop temperatures, pressures, flow, pump state, CDU status, leak detection, phase-level power, UPS and battery behavior, vibration, generator state, and grid-interface telemetry. [OCP telemetry work](https://www.opencompute.org/documents/ocp-wp-dcf-improve-data-center-cooling-facility-efficiency-through-platform-power-telemetryr1-0-final-update-pdf) catalogs base-building and data-hall points across utility, generation, central plant, power monitoring, cooling, environmental, and liquid-cooling systems.

The harder issue is not only volume. It is a timescale mismatch. GPU power can change in seconds or less. Electrical protection events can unfold in cycles. Cooling loops respond more slowly. Building systems often trend at minute cadence. The data layer has to preserve those cadences without flattening them into averages that erase the sequence operators need to reconstruct. Traditional facility telemetry was often sampled at minute-level cadence because the use case was monitoring, trending, and capacity planning. OCP notes that minute-level power sampling was commonly used to reduce network impact. AI workload telemetry, by contrast, is routinely collected at one-second or finer resolution, and the workload itself moves in synchronized phases. A [756-GPU academic cluster study](https://arxiv.org/abs/2604.04745) collected 162 GB of per-second telemetry over 31 days. [SemiAnalysis](https://newsletter.semianalysis.com/p/ai-training-load-fluctuations-at-gigawatt-scale-risk-of-power-grid-blackout), citing Meta's Llama 3 infrastructure, describes tens of megawatts of instantaneous power fluctuation from synchronized GPU behavior on a 24,000-H100-class cluster with about 30 MW of IT capacity. [Meta separately documented two 24,576-GPU clusters](https://engineering.fb.com/2024/03/12/data-center-engineering/building-metas-genai-infrastructure/) used for Llama 3 training. [NERC's July 10, 2024 incident review](https://www.nerc.com/globalassets/our-work/reports/event-reports/incident_review_large_load_loss.pdf) documented approximately 1,500 MW of customer-initiated, voltage-sensitive load reduction after a 230 kV transmission fault sequence, six faults in an 82-second period.

The operational result is simple and uncomfortable: slow facility telemetry and fast workload telemetry now have to live in one data layer, with enough fidelity to be queried together. The data model has to respect OT boundaries, preserve local autonomy, and still support building, campus, and enterprise rollup. It has to fit the systems already in place rather than ask the facility to reorganize itself around a database.

That is the architecture this paper lays out: a PostgreSQL-native time-series layer, implemented with [TimescaleDB](https://www.tigerdata.com/docs), present at each Purdue scope, behind SCADA and the operational applications rather than in place of them, integrated through OT protocols, compressed and rolled up the hierarchy on premises, and optionally synchronized to a managed cloud only when policy allows.

## Data-Layer Requirements

The reference architecture starts with requirements, because the failure mode is rarely a missing connector or a single slow query. It is a data layer that satisfies one requirement while violating another. For AI data center operations, the following have to hold together.

**Sustained high-frequency, high-cardinality ingest.** The ingest path must support continuous streams from GPUs, power chain, cooling chain, BMS, PMS, CDU, leak detection, vibration, battery, and grid-interface systems, and keep insert behavior stable as tags, devices, tenants, halls, and derived metrics grow.

**Years of history online and affordable.** Operators need recent high-resolution data for incident response, but capacity planning, model-based optimization, energy analysis, and failure prediction depend on long histories. Aging data cannot disappear into cold archives that need a separate restore path before they can answer a question.

**Concurrent real-time and analytical access.** The same operational data estate has to serve live dashboards, alarm investigation, root-cause analysis, fleet comparison, efficiency studies, and long-running analytical queries. Isolation matters, but copying data into disconnected stores for every audience defeats the point of a facility-wide operating record.

**Edge-to-enterprise rollup with local autonomy.** Data is born locally. A hall must keep recording if the building rollup is unavailable, and a building must keep operating if the campus link is down. Rollup should be delayed, replayed, and reconciled without changing the identity or semantics of the data.

**Reliability and durability as baseline behavior.** High availability, automatic failover, incremental backup, point-in-time restore, and operational visibility are not convenience features in this environment. They are part of the minimum viable design for operational infrastructure.

**Deployment where the data lives.** The primary target is on-premises, at the edge, in the data center, or in a customer-managed environment. Air-gapped and intermittently connected sites must be first-class designs, not exceptions.

## Reference Architecture: A Time-Series Data Layer at Every Purdue Scope

![](https://storage.ghost.io/c/6b/cb/6bcb39cf-9421-4bd1-9c9d-fa7b6755ba0e/content/images/2026/07/diagram-1.png)

__The AI Data Center Telemetry Stack. A time-series data layer sits behind SCADA, HMI, MQTT, and operational applications at the hall and building scopes. Deterministic control stays local. Operational data rolls up on premises from hall to building to campus to enterprise, with optional managed-cloud synchronization shown as a separate path. Purdue layers are logical operating scopes; actual network segmentation varies by site.__

The reference architecture places a time-series data layer at each operational scope of the Purdue model. Treat those scopes as logical, not as strict network boundaries. In many industrial environments Purdue Layers 2 and 3 share a subnet or operational network, so the layers describe responsibility and rollup position, not mandatory physical segmentation. This does not move control into the database. Deterministic control loops stay in PLCs, controllers, protection systems, BMS, PMS, CDU controllers, and SCADA. The database observes, stores, aggregates, and serves. It does not sit in the deterministic control path.

The key architectural choice is consistency: the same time-series technology runs at each scope, scaled to that scope's responsibility, with data rolling up the hierarchy. Rollup becomes a native data architecture instead of a chain of one-off translations between incompatible stores.

### Layers 0 and 1: instrumentation, control, and local capture

Field devices and control assets produce the raw state: meters, breaker monitors, rPDUs, UPS telemetry, CDUs, leak sensors, valve positions, pump speeds, pressure transducers, flow meters, temperature and vibration sensors, PLC tags, BMCs, and GPU node telemetry. Collection happens through industrial gateways, collectors, or local agents adjacent to the control network.

Accepted ingress patterns include OPC UA for structured industrial data, Modbus and BACnet where building and equipment systems already expose them, MQTT for brokered publish and subscribe, Redfish for server and hardware management telemetry, and SNMP where power and network equipment still emit it. [OCP's telemetry guidance](https://www.opencompute.org/documents/ocp-wp-dcf-improve-data-center-cooling-facility-efficiency-through-platform-power-telemetryr1-0-final-update-pdf) explicitly covers MQTT, Redfish, TLS and mTLS, push and pull, publish and subscribe, Modbus, BACnet, segmentation, and secure data exchange across the OT and IT boundary.

At this layer the local database footprint can be small. Its job is short-horizon buffering, timestamp integrity, store-and-forward behavior, and protection against upstream loss. It should run on industrial PCs or local edge servers without introducing a dependency into the control loop.

### Layer 2: hall operations and the hall historian

Layer 2 is the hall-level operating environment. This is where the supervisory and application systems live: SCADA and HMIs, Ignition, MQTT brokers, and the hall-level applications operators work day to day. The time-series data layer does not replace any of them. It sits behind and alongside them as [the hall historian](https://www.tigerdata.com/learn/scada-data-management-at-scale-architecture-historians-and-the-modern-database): the durable, queryable record of what the hall did.

A hall-level time-series store is the reference pattern, because it gives each hall a complete, durable local record and lets it stay available on its own. Not every deployment starts there. Some facilities run the data layer at the building scope and above and aggregate hall telemetry there, then add hall-level stores as availability requirements, complexity, and the need for local autonomy grow. The architecture supports both: the hall tier scales in where those requirements justify it, while the rollup hierarchy stays the same.

Where deployed, each hall-level time-series store ingests high-frequency telemetry for that hall, receiving it through Ignition gateways, MQTT brokers, OPC UA bridges, protocol gateways, collectors, and application connectors. SCADA remains the supervisory environment, the HMIs remain the operator interface, and MQTT remains the brokered transport where it is already used. Against that, TimescaleDB provides durable high-resolution history, SQL access, compression, continuous aggregates, and local query performance. It serves historical queries behind the local dashboards and preserves operational history during disconnection from upper scopes: if the link to building or campus is unavailable, Layer 2 keeps recording. SCADA and the HMIs remain the operator's real-time supervisory surface; the historian is what they query when the question is what happened, when, and in what order. Order matters here, and so does context: because TimescaleDB is PostgreSQL, writes land in ACID transactions, and the historian can preserve the recorded sequence with the timestamp, source, and quality context needed to reconstruct event order.

This is where high-cardinality ingest matters most. A hall can contain thousands of accelerators, dense liquid-cooling loops, high-frequency power instrumentation, and multiple local systems previously operated in separate views. The Layer 2 historian should answer immediate operator questions: what changed in this hall, which CDU loop moved first, which racks saw the phase imbalance, what the GPU power profile did, and which protection or backup systems responded.

### Layers 2.5 and 3: sub-zone, building, and SCADA adjacency

Layers 2.5 and 3 aggregate across halls, rooms, mechanical zones, electrical lineups, and building systems. In practice these scopes often share an operational network with Layer 2 rather than sitting on a separate tier; the distinction is one of rollup responsibility, not necessarily of subnet. This is the integration point for SCADA, BMS, PMS, DCIM, MQTT brokers, message buses, and operational applications.

The data layer sits alongside SCADA, not in place of it. SCADA remains the supervisory interface and control environment at both the hall and building scopes. The time-series layer is the durable, queryable substrate behind real-time views, historical analysis, external reporting, and analytics.

The strongest proof point for this fit is the [strategic alliance between Inductive Automation and Tiger Data](https://www.tigerdata.com/newsroom/inductive-automation-and-tiger-data-collaborate-to-modernize-the-industrial-historian-market), the company behind TimescaleDB, announced in April 2026 to modernize the industrial historian. Inductive Automation makes Ignition, a widely deployed industrial application and SCADA platform; [TimescaleDB Enterprise](https://www.tigerdata.com/newsroom/tiger-data-launches-timescaledb-enterprise-a-self-managed-time-series-database-built-for-on-premises-and-edge-deployment) (in early access; [sign up to become a design partner](http://design-partner-signup-tbd)) is an on-prem PostgreSQL-based time-series database that serves as the historian behind it, for on-premises and edge deployment. For operators already standardizing on Ignition, that makes the database an integrated historian path rather than a parallel system the operations team has to glue together alone.

### Layers 4 and 5+: campus, enterprise, and cross-site analytics

At Layer 4 and Layer 5+, data rolls up for campus operations, cross-building comparison, capacity planning, reporting, fleet analytics, and AI or machine-learning workflows. This scope does not need every raw sample forever at the hottest resolution. It needs governed rollups, selected raw windows, and enough fidelity to reconstruct operational behavior when an incident crosses halls, buildings, or grid boundaries.

The rollup itself is the heart of the architecture, and it runs on continuous synchronization between scopes: hall to building, building to campus, campus to enterprise. Where supported, planned synchronization capabilities move selected raw streams, rollups, and metadata upward between TimescaleDB stores, so an upper scope holds a faithful, current view without the lower scope losing autonomy or identity. Critically, this rollup stays inside the operator's own infrastructure. It does not require the cloud.

Moving data from the on-premises hierarchy to Tiger Cloud is a separate concern. For organizations that want managed cross-site analytics, planned synchronization capabilities can provide an optional path to Tiger Cloud, where [tiered storage](https://www.tigerdata.com/docs/learn/data-lifecycle/storage/about-storage-tiers) keeps frequently queried data in a high-performance tier and moves older data to object storage. Tiger Cloud documentation describes up to 64 TB in the high-performance tier depending on plan, with a low-cost object storage tier behind it. That path is optional and cloud-bound. The on-premises hierarchy is complete without it: for sites that cannot send operational data out, the full edge-to-enterprise rollup still runs, entirely self-managed.

## Operator Scenario: Reconstructing a Load Event

A training job enters a synchronized phase. GPU power draw rises across a hall, phase-level power telemetry moves, one CDU loop responds before the others, and UPS or battery telemetry shows a corresponding event. The hall historian preserves the high-resolution sequence locally. The building rollup shows whether the response crossed halls or stayed local. The campus view shows whether the event aligned with broader electrical posture. The operator does not need five disconnected exports to reconstruct the event. The data layer preserves source, timestamp, unit, quality, and lineage so the question can be asked across systems without losing the order of operations.

## Why TimescaleDB Fits This Architecture

The requirements above point to a single system. The data layer has to speak SQL, keep time-series data bounded as it grows, compress years of history into affordable storage, roll up cleanly from edge to enterprise, and run reliably on hardware the operator controls. TimescaleDB is a PostgreSQL extension that does all of that in one engine.

Because it is an extension and not a fork, it keeps standard PostgreSQL clients, drivers, and SQL, and adds hypertables, continuous aggregates, compression, and retention. The data layer fits the tooling operations and analytics teams already run: drivers, BI tools, Grafana, backup tooling, access-control patterns, and the operational knowledge already in the building. There is no proprietary query language to learn and no silo that only one vendor's tools can read.

[Hypertables](https://www.tigerdata.com/docs/learn/hypertables/understand-hypertables) answer the volume problem. They partition by time, so ingest, retention, compression, and queries operate over chunks instead of one ever-growing table that eventually degrades. [Continuous aggregates](https://www.tigerdata.com/docs/learn/continuous-aggregates) answer the rollup requirement. They maintain incrementally refreshed views, including rollups over rollups, which maps directly onto the Purdue hierarchy: raw hall data rolls into minute, hourly, and daily views; building aggregates roll into campus views; selected metrics feed enterprise models.

Compression is what makes long online retention practical. Tiger Data's [IIoT performance work](https://www.tigerdata.com/blog/how-timescaledb-expands-postgresql-iiot-performance-envelope) reports common compression ratios of 80 to 95 percent, with a terabyte of raw data compressing to roughly 50 to 100 GB. [Hypercore](https://www.tigerdata.com/docs/learn/columnar-storage/understand-hypercore), the hybrid row and columnar engine behind this, lands new data in a row-oriented path for ingest and updates, then moves older data into columnar storage for compression and analytical scans. One table serves both the operator querying the last hour and the analyst scanning the last year.

On ingest, the honest claim is sustained production scale, not a record for peak rows per second on a narrow benchmark. The partitioning model exists to prevent the failure mode where a single PostgreSQL table grows until inserts and queries fall over. [Direct Compress](https://www.tigerdata.com/blog/introducing-direct-compress-up-to-40x-faster-leaner-data-ingestion-for-developers-tech-preview), a TimescaleDB 2.21 tech preview from September 2025, compresses data in memory during COPY ingestion and reports up to 40x faster ingestion in its benchmark scenario, with the usual caveat that schema, batching, storage, and workload shape change the result. AI data center telemetry is won by keeping ingest, SQL access, compression, rollup, retention, security, and operations in one reliable system, not by a drag race.

## Reliability Where Operations Actually Run

The guarantees you were promised, on your own hardware.

Operations teams have spent years being told that critical data infrastructure should behave like a managed service: high availability, automatic failover, incremental backup, point-in-time restore, operational dashboards, controlled upgrades, and recovery that does not depend on a hero at 3 a.m. The requirement is right. The deployment assumption is wrong. Many AI data center environments cannot make a managed public cloud service the dependency of record for OT data.

[TimescaleDB Enterprise](https://www.tigerdata.com/newsroom/tiger-data-launches-timescaledb-enterprise-a-self-managed-time-series-database-built-for-on-premises-and-edge-deployment) is the self-managed answer to that constraint: the open-source TimescaleDB engine plus the operations layer, licensed for on-premises, edge, and customer-managed cloud, and built to run air-gapped. The operations layer is the point. High-availability clustering, automatic failover, fully incremental backups, and point-in-time recovery put managed-grade behavior on hardware the operator owns. A web-based admin console and pre-configured Grafana dashboards make that behavior visible instead of tribal.

Because the engine is the same at every scope, each layer can be operated to the criticality of its function. A Layer 2 hall historian runs locally and stays durable through an upstream outage. A Layer 3 building store runs with replicas and failover. A Layer 4 campus store aggregates across buildings without forcing every hall to depend on the campus link. Backup and restore are part of the operating model, not an export script someone has to remember to run.

Two data paths leave each site, and the distinction matters. On-premises rollup moves selected raw streams, rollups, and metadata up the hierarchy while each local system stays complete on its own. Cloud synchronization is a separate, optional path for organizations that want cross-site analytics in Tiger Cloud. For air-gapped sites, regulated sites, and facilities where policy, latency, or operational independence keeps OT data local, the rollup path runs without the cloud path ever being enabled.

## Operating Model and Guardrails

The architecture should be deployed with clear boundaries.

First, keep the database out of the control loop. It can record telemetry and serve queries, but a database issue must never affect trip logic, PLC scans, protective relays, CDU control, or BMS control loops.

Second, keep the storage technology consistent across scopes. When the same time-series engine runs at the hall, the building, the campus, and the enterprise, a query written against a hall historian stays valid against a campus rollup, and identities, units, and retention policies carry upward without reinterpretation. Consistency at this level is what turns rollup from an integration project into a property of the system.

Third, keep identities stable across rollup. A tag, device, rack, CDU, UPS, hall, tenant zone, or GPU should not get a new identity at every layer. The rollup path should preserve source, timestamp, quality, unit, and lineage.

Fourth, design for replay. Local stores need bounded queues and retention windows that let them backfill upstream systems after a link outage. The system should assume disconnection, not merely tolerate it.

Fifth, separate raw, operational, and analytical views. Operators need recent raw and high-resolution data; building and campus teams need rollups; enterprise analytics needs governed datasets. Hypertables, compression policies, retention policies, and continuous aggregates provide the database-level primitives for that separation.

Finally, make reliability visible. HA state, replica lag, backup freshness, restore validation, ingest lag, compression job health, disk headroom, and query saturation belong on the operational dashboard. A database holding operational telemetry becomes part of the facility's own instrumentation.

## The Operator's Goal

The data layer is not the goal. Energizing the build is the goal. Keeping the facility stable through synchronized workload behavior is the goal. Running power and cooling close to the real operating envelope, without sacrificing margin blindly, is the goal. Planning the next tranche of capacity with evidence instead of guesswork is the goal.

A time-series layer earns its place only if it serves those outcomes. It has to fit the SCADA and protocol stack already in place. It has to keep years of history online without making storage economics impossible. It has to serve real-time and analytical access without splitting the operating record. It has to roll up from edge to enterprise while letting every local layer keep running when the link drops. And it has to deliver reliability and durability on hardware the operator controls.

That is the reference architecture: TimescaleDB as the PostgreSQL-native time-series data layer, present at each Purdue scope, sitting behind SCADA and the operational applications rather than replacing them, integrated through OT protocols, compressed and rolled up the hierarchy on premises from hall to building to campus to enterprise, operated locally, and optionally synchronized to Tiger Cloud only when policy allows.

The physical plant is now part of the computer. The data layer has to be built like that is true.

## Get Started

Interested in managed time-series analytics? Start a free [Tiger Cloud trial](https://console.cloud.timescale.com/signup).

Running on-premises, at the edge, or in an air-gapped environment? TimescaleDB Enterprise is built for those deployments and is accepting [design partners](https://www.tigerdata.com/timescaledb-enterprise#form-section).