---
title: "Smart Grid Data Platform: Architecture Guide"
description: " Learn how a smart grid data platform unifies SCADA, AMI, PMU, and DERMS telemetry into one queryable Postgres database, with real customer results."
section: "Postgres for IoT"
---
> **TimescaleDB is now Tiger Data.**
A modern smart grid runs on four telemetry systems that were never designed to talk to each other. A SCADA historian tracks distribution-level voltage, current, and breaker status. A meter data management (MDM) system processes advanced metering infrastructure (AMI) interval reads from every household and business on the network. A wide-area measurement system (WAMS) ingests phasor measurement unit (PMU) data at rates most databases were never built to sustain. And a distributed energy resource management system (DERMS) coordinates batteries, solar inverters, and EV chargers in near-real-time. Each system does its job well. None of them can answer a question that spans more than one of them.
Full disclosure up front: Tiger Data builds a PostgreSQL database, available as the open-source TimescaleDB extension or as Tiger Cloud, the fully managed service, and this guide naturally points toward that architecture. That said, a general-purpose time-series database is not the right fit for every part of a smart grid stack, and this guide says so plainly where that's true. The goal here is to provide a framework for evaluating your data layer.
This guide is scoped to the data layer specifically: how grid telemetry gets ingested, stored, retained, and queried. It does not cover grid hardware, communication protocols, standards bodies, or utility regulation, except where those topics directly shape a database decision. For the broader picture of how Tiger Data supports energy and utilities workloads beyond the grid telemetry layer, see [Postgres for Energy & Utilities](https://www.tigerdata.com/energy-utilities).
Four data types drive everything that follows. SCADA telemetry reports breaker status, voltage, and load from substations and feeders on a seconds-to-minutes cadence. AMI data delivers 15-minute or hourly consumption reads from every meter on the network. PMU data streams synchrophasor measurements up to 120 times per second per device for grid stability monitoring. DERMS telemetry coordinates real-time signals to and from thousands of distributed batteries, inverters, and chargers. A smart grid data platform is what makes it possible to query all four together, in one system, with standard SQL.
## What is a smart grid data platform?
A smart grid data platform is the unified data infrastructure, typically a time-series or general-purpose database, that ingests, stores, and serves query access to grid telemetry across SCADA, AMI, PMU, and DERMS systems. It replaces the default pattern of four siloed stores: a historian for OT data, an MDM for meter reads, WAMS-specific tooling for PMU streams, and a narrow proprietary data store built into the DERMS platform itself.
This is an infrastructure concept, not a commercial product category. That distinguishes it from named application-layer platforms like Schneider Electric's grid software, Tantalus, or GE Vernova GridOS. Those products coordinate grid operations and decision-making, and utilities buy them to solve specific operational problems: outage management, demand response, distribution automation. None of them replace the need for a data layer underneath. They still read from and write to some store of telemetry, and how well that store handles cross-domain queries, long-term retention, and ingest volume shapes how well the application layer performs on top of it. That data layer, not the coordination software sitting above it, is what this guide is about.
## What data does a smart grid generate?
Four distinct data streams make up the bulk of grid telemetry today, and each currently lives in its own purpose-built system. None of those systems were designed to answer a question that spans more than one data type, such as whether a DER response actually reduced load on a specific feeder during a PMU-flagged stability event. That cross-domain gap is the throughline for the rest of this guide.
### SCADA and distribution telemetry
Substations and feeders report breaker and switch status, voltage, current, and load readings, typically polled on a cadence ranging from seconds to minutes. This is the traditional data historian workload, the same category covered in Tiger Data's [data historian](https://www.tigerdata.com/learn/what-is-a-data-historian) reference page. SCADA data is well-understood and well-served by decades of historian tooling. The limitation shows up when a utility needs to correlate it with the other three data types below.
### AMI and smart meter interval data
Advanced metering infrastructure (AMI), the industry term for smart meter networks, generates interval consumption reads, typically every 15 minutes or hourly, from potentially millions of endpoints. Beyond consumption, AMI systems also generate event data: outage pings, tamper flags, and voltage events reported as they happen. A mid-size utility with 100,000 AMI endpoints reporting hourly produces roughly 2.4 million meter readings a day, before counting event data. That volume doesn't fit the batch, monthly-scalar model most billing-oriented systems were built around.
### PMU and wide-area measurement (WAMS) data
Phasor measurement units (PMUs) report synchrophasor data, voltage and current phasors with precise time synchronization, at rates up to 120 measurements per second per device. For scale, a large utility PMU network can generate on the order of a terabyte of data per month. Treat that as directional - PMU deployment size varies widely by utility and region
A common assumption needs correcting here: PMU data is primarily a transmission bandwidth and real-time-processing problem, not a storage-sizing problem. Getting synchrophasor data reliably to the control center at line rate, and processing it fast enough to act on grid stability events, is the harder half of the challenge. Storage and compression are comparatively the easier half to solve. Some industry compression approaches claim ratios as high as 1000:1 for full waveform capture, though that figure should be read as a directional claim about the compressibility of PMU waveforms rather than a specific product's verified benchmark.
### DERMS and distributed energy resource (DER) telemetry
Distributed energy resources, DERs, are the batteries, solar inverters, EV chargers, and other customer- and grid-edge assets that a DERMS platform coordinates in near-real-time. The coordination challenge is as much about volume as it is about speed. DERMS platforms increasingly need to ingest and act on signals from thousands to tens of thousands of individual devices, each reporting frequently. That stream then has to turn into dispatch decisions fast enough to matter operationally.
This is the core of what makes DERMS architecturally different from the other three data types. SCADA, AMI, and PMU systems are largely one-directional, collecting readings from fixed infrastructure. DERMS telemetry is bidirectional and rapidly growing in both device count and reporting frequency as distributed generation and storage scale. A data layer built for DERMS has to keep pace with that growth without a redesign every time the device count doubles.
Battery energy storage systems (BESS) are one of the clearer examples of this growth pattern in practice. Cactos, a manufacturer and operator of battery storage systems, [migrated its time-series workload off Amazon RDS](https://www.tigerdata.com/blog/how-cactos-migrated-from-amazon-rds-and-cut-costs-by-55) as its fleet-level telemetry volume outgrew what a general-purpose relational database on RDS could handle cost-effectively, cutting database costs 55% in the process. EV charging infrastructure follows a similar trajectory: as fleets of chargers scale from dozens to thousands, the [database architecture behind an EV charging management system](https://www.tigerdata.com/learn/ev-charging-station-data-management) has to absorb the same kind of device-count growth DERMS platforms face more broadly.
## Why legacy infrastructure hits limits
Each of the systems utilities currently rely on for grid telemetry has a specific, well-documented failure mode. None of them are broken in the sense of failing at their original job. They hit limits because the data they were designed for has changed shape and volume around them, a pattern covered in more general terms in Tiger Data's guide to [IoT energy data at scale](https://www.tigerdata.com/blog/iot-energy-data-at-scale-engineering-solutions-beyond-legacy-historians).
**Data historians** were built for OT environments: proprietary storage formats, tight integration with PLCs and SCADA systems, and weak or nonexistent SQL access. That design works well for single-domain, high-frequency process data. It breaks down as soon as a team tries to layer AMI or DER data on top of a system architected for substation telemetry alone, since the historian has no native concept of meter reads or DER dispatch signals.
**Legacy MDM systems** were architected for the AMR era, monthly, scalar meter reads collected for billing. AMI's continuous interval data doesn't fit that model. The common failure pattern: a utility bolts a modern AMI head-end onto a decades-old billing system via batch file exchange. The exception queue (records that failed validation and need manual review) grows every billing cycle as data volume increases. Large-vendor MDM deployments commonly take 12 to 18 months from contract signature to go-live, a timeline that reflects how much custom integration work sits between AMI ingest and a billing system never designed for it.
**WAMS-specific tooling** handles PMU ingest capably but is siloed from SCADA, AMI, and DERMS data by design. There's no cross-domain query path built in, because WAMS tools were purpose-built for one job: getting synchrophasor data to the control center reliably.
**DERMS platforms** often ship with a narrow, built-in data store that's adequate for real-time coordination, the immediate job of dispatching signals to distributed assets, but not designed for longer-term, cross-system analysis. That's a reasonable tradeoff for the platform's core function. It becomes a limitation the moment someone wants to analyze DER performance alongside SCADA or AMI history.
The shared root cause across all four: each system solves one slice of the grid telemetry problem well, and none of them was designed to answer questions that span systems.
Unifying the data layer is a technical fix, and it's the one this guide focuses on. Utilities also report a real organizational dimension to data silos: teams pursuing the same reliability goals within the same utility often don't share data even when nothing technical prevents it. A database migration doesn't resolve that half of the problem. Both halves usually need attention.
## What a smart grid database needs to do
Before mapping any of this to a specific product, here are the requirements stated plainly, as a checklist rather than a feature list.
**High-frequency ingest without loss, including bursts.** PMU data can spike to 120 samples per second per device. The database needs to sustain that write rate without dropping readings, including during grid events when data volume and urgency both increase at once.
**Long-term retention with fast query access.** This isn't just cold archival storage. Operations and planning teams need to query historical patterns, not just retrieve a value from six months ago. Retention that isn't queryable doesn't meet the actual requirement.
**Multi-source joins.** The ability to query SCADA, AMI, PMU, and DERMS data together in one schema, using SQL, rather than exporting from four systems into a spreadsheet to answer a cross-domain question manually.
**Downsampling and rollups.** Dashboards and long-range trend analysis need pre-aggregated views so the system isn't re-scanning raw, high-frequency data on every query. For example, the [Embodied Carbon Observatory](https://www.tigerdata.com/blog/how-embodied-carbon-observatory-separates-grid-improvement-real-decarbonization-tiger-data) analyzes grid-improvement data to separate real decarbonization from grid-side accounting changes. After moving to this kind of pre-aggregated, time-partitioned architecture, it cut query times from 6 seconds to under 100 milliseconds, the difference between a dashboard that's usable in an analyst's workflow and one that isn't.
**SQL accessibility.** Grid operations and analytics teams generally already know SQL. A database that requires a proprietary query language adds a training and hiring cost that a SQL-native system doesn't.
## Grid software and DERMS workloads
DERMS platforms coordinate real-time signals to and from distributed batteries, solar inverters, and EV chargers, aggregating individually small resources into capacity a grid operator can actually dispatch against. That coordination job is a distinct workload from data storage, and increasingly, DERMS architecture guidance recommends separating the two.
A two-tier storage pattern has become common industry guidance for DERMS deployments: hot storage in a time-series database for recent, high-query-frequency data, paired with cold storage, typically a data lake or object storage, for long-term retention. This reflects a broader industry recognition that DERMS coordination and DERMS data retention are different problems with different access patterns.
Industry coverage increasingly treats DERMS as operationally co-equal to SCADA, not a secondary system bolted on as an afterthought. That shift in framing matters because it explains why DERMS deserves the same data-architecture rigor that SCADA has received for decades. As distributed generation and storage scale, the volume and criticality of DER telemetry is approaching, and in some grids exceeding, the criticality of the SCADA data utilities have always treated seriously.
One point of confusion worth resolving directly: DERMS is not the same thing as ADMS (Advanced Distribution Management System). DERMS coordinates distributed energy resources specifically, batteries, solar inverters, EV chargers. ADMS manages the broader distribution grid, including switching operations and outage management. The two systems increasingly need to share data with each other even though they serve different operational functions, and that data-sharing need is itself another argument for a queryable layer underneath both.
This guide stays focused on the data and architecture angle rather than comparing DERMS vendor products. Itron, Landis+Gyr, Oracle Utilities, and GE Vernova are platform vendors solving the coordination problem, not database competitors, and a vendor comparison between them is out of scope here.
A dedicated guide on DERMS and unifying DER data across systems, sometimes called the "single source of DER data" problem, is planned as a follow-up to this piece and will go deeper into that specific workload.
## Database architecture options
None of these four patterns is universally correct. The right choice depends on which data types a utility is handling, how much cross-domain querying it actually needs today, and how much of its existing investment in historian or WAMS tooling still has useful life left. The table below compares the four architecture patterns utilities choose among today for grid telemetry: a data historian, a DERMS platform's built-in store, WAMS-specific tooling, and a general-purpose time-series database on PostgreSQL.
| **Architecture** | **What it's built for** | **Strengths** | **Limitations** | **Not suited for** |
| --- | --- | --- | --- | --- |
| Data historian | OT process data at the substation/feeder level | Tight PLC/SCADA integration, proven at scale for single-domain data, reliable compression | Proprietary formats, weak or no SQL access, not designed for meter or DER data types | Cross-system analytics, AMI-scale ingest, DERMS coordination data |
| DERMS platform's built-in store | Real-time coordination and dispatch of distributed assets | Optimized for the coordination workload it ships with | Narrow data model, not built for long-term cross-system analysis | Long-term retention, cross-domain queries with SCADA/AMI/PMU history |
| WAMS-specific tooling | High-rate PMU/synchrophasor ingest | Handles burst ingest at required sample rates | Siloed from SCADA, AMI, and DERMS data; no cross-domain query path | Multi-source analytics, general operational reporting |
| General-purpose time-series database (PostgreSQL/Tiger Data’s TimescaleDB) | Cross-system ingest, storage, and SQL query across all four data types | Standard SQL, multi-source joins, long-term compressed retention that stays queryable | Not a substitute for purpose-built real-time control or protection systems requiring microsecond, hardware-level response | Microsecond-latency protection relays, hardware-level real-time control |
Community discussion and some industry write-ups associate InfluxDB with grid telemetry use cases, though that association reflects general time-series adoption patterns rather than a specific market-share claim for the grid sector. If AWS Timestream comes up in a vendor evaluation, note that Timestream LiveAnalytics was deprecated to new customers in June 2025 and is no longer a viable option to evaluate. The surviving product, Timestream for InfluxDB, is a managed InfluxDB service and worth a brief mention rather than a full comparison row here.
This table extends the same comparison pattern used in Tiger Data's [water utilities database](https://www.tigerdata.com/learn/water-utilities-database-how-to-store-query-scada-ami-quality-data-at-scale) guide, historian versus MDM versus general-purpose time-series database, adding the WAMS and DERMS rows specific to electric grid telemetry.
## Proof point: how Plexigrid replaced four databases with one
[Plexigrid](https://www.tigerdata.com/blog/from-4-databases-to-1-how-plexigrid-replaced-influxdb-got-350x-faster-queries-tiger-data) is a distribution system operator (DSO) software vendor serving low-voltage grid optimization customers across North America and Europe. Its platform gives DSOs near-real-time visibility into load, voltage, and constraint violations across the distribution grid, the kind of granular observability that decentralized, bidirectional power flows increasingly require.
Plexigrid's initial proof of concept ran four separate databases: InfluxDB for time-series telemetry, TigerGraph for grid topology, and both MySQL and PostgreSQL for relational and analytical workloads. That stack worked for a proof of concept. It didn't hold up operationally. Running and integrating four databases across every new DSO deployment became expensive and brittle, and InfluxDB's ingestion behavior at scale was the specific bottleneck: resource needs were hard to predict, and when sizing was off, ingestion failed outright.
Plexigrid consolidated all four systems into a single PostgreSQL and TimescaleDB instance. The results, measured against the prior InfluxDB-based stack: 350 times faster queries, from 5 minutes down to 0.5 seconds; 44% faster ingest; and a 95% storage reduction, from roughly 350GB down to 3GB, achieved through hypercore's columnstore compression.
"Using a unified PostgreSQL/TimescaleDB architecture reduced maintenance overhead and gave us consistent deployment options," said Enrique Riesgo, Chief Software Engineer at Plexigrid.
The architecture takeaway is the same pattern this entire guide argues for: consolidating four purpose-built systems into one queryable data layer, rather than maintaining separate stores for telemetry, topology, and relational data, is what made the platform both cheaper to run and faster to query. This is proof of the pattern working at production scale.
Read the [full Plexigrid case study](https://www.tigerdata.com/blog/from-4-databases-to-1-how-plexigrid-replaced-influxdb-got-350x-faster-queries-tiger-data) for the complete migration story.
## Getting started: connecting SCADA, AMI, and DERMS feeds
Two protocols dominate the path from field systems into a modern data pipeline: OPC-UA, common on the SCADA and industrial side, and MQTT, common across DERMS and IoT-style telemetry. A typical ingest path runs field devices through OPC-UA or MQTT into a broker, such as [EMQX](https://www.tigerdata.com/docs/integrate/data-ingestion-streaming/emqx) or [HiveMQ](https://www.tigerdata.com/docs/integrate/data-ingestion-streaming/hivemq), then writes into a database table structured for time-series data. Legacy historian exports can feed the same pipeline on a batch basis where a direct real-time feed isn't yet available, which keeps the historian in place as the SCADA control layer while the analytics layer builds up in parallel.
A common schema can hold SCADA, AMI, and DERMS readings side by side, since all three ultimately share the same shape: a device or asset identifier, a timestamp, a signal type, a value, and the source system it came from. Here's an illustrative [hypertable](https://www.tigerdata.com/docs/learn/hypertables/understand-hypertables) definition (not a full production schema):
`CREATE TABLE grid_telemetry (
time TIMESTAMPTZ NOT NULL,
asset_id TEXT NOT NULL,
source_system TEXT NOT NULL, -- 'scada', 'ami', 'pmu', 'derms'
signal_type TEXT NOT NULL, -- e.g. 'voltage', 'kwh_interval', 'freq'
value DOUBLE PRECISION,
quality_flag INTEGER
) WITH (
timescaledb.hypertable,
timescaledb.partition_column = 'time',
timescaledb.segmentby = 'asset_id, source_system',
timescaledb.orderby = 'time DESC'
);`
With that table in place, a [continuous aggregate](https://www.tigerdata.com/docs/learn/continuous-aggregates) handles rolling averages without re-scanning raw data on every query, useful for feeder-level or device-level dashboards:
`CREATE MATERIALIZED VIEW feeder_15min_avg
WITH (timescaledb.continuous) AS
SELECT
asset_id,
source_system,
time_bucket('15 minutes', time) AS bucket,
avg(value) AS avg_value,
max(value) AS max_value,
min(value) AS min_value
FROM grid_telemetry
GROUP BY asset_id, source_system, bucket;`
Recent data needs to stay in row form for fast writes, while older telemetry compresses down for efficient long-term storage. Because the CREATE TABLE above already enables the columnstore, TimescaleDB automatically compresses chunks once they age past the 7-day chunk interval — no separate policy call is needed.
The retention pattern that results: data younger than the policy threshold stays hot and fast to write; data older than that compresses down dramatically, echoing the 95% storage reduction Plexigrid saw in production, while remaining fully queryable in standard SQL rather than archived somewhere out of reach.
## Where this series is headed
This guide is the first in a planned series covering smart grid data architecture in depth. Future installments will go deeper into meter data management and AMI, DERMS and the single-source-of-DER-data problem, and grid modernization data platforms more broadly, each addressing the specific workload in more detail.
## Decision framework: choosing a data layer for smart grid workloads
### Choose a unified time-series database layer if:
You're running SCADA, AMI, PMU, or DERMS telemetry, or more than one of these, and need to query across systems without exporting data between them by hand. Your team already knows SQL and wants to avoid learning a proprietary historian or WAMS query language. You need both fast recent-data queries and cost-efficient long-term retention in the same system, rather than maintaining a separate archive.
### Choose to keep your historian in place (for now) if:
Your primary need is OT-side, single-domain SCADA data with no cross-system query requirement, and your historian is meeting that need today. A migration isn't justified yet if query performance and storage cost aren't currently causing operational pain.
### Choose a specialized, purpose-built tool alongside your database if:
You need microsecond-level, hardware-driven real-time control or protection response. That's not a general-purpose database's job, and a modern time-series database should sit alongside, not replace, that layer. Your PMU or WAMS ingest is bottlenecked by transmission bandwidth to the control center rather than by storage or query speed, which is a networking and protocol problem to solve first.
## Common migration paths
**Consolidating multiple purpose-built systems into one.** Plexigrid is the clearest example: a telemetry database, a graph database, and two relational databases, consolidated into a single PostgreSQL and Tiger Data instance. This path fits utilities and grid software vendors running several specialized stores that have become expensive to integrate and maintain in parallel.
**Migrating off a legacy historian.** This path typically starts when cross-domain queries, SCADA and AMI and DERMS data together, become a recurring operational need the historian simply can't serve.
**Migrating off a general-purpose relational database that has hit limits.** Some teams run grid telemetry on vanilla Postgres, Microsoft SQL Server, or another RDBMS and eventually hit ingest or retention ceilings. Axpo, an energy company, hit exactly this wall: its Microsoft SQL Server deployment filled up after connecting just two power plants, and the system stalled. Axpo's IoT platform now [ingests roughly 150 million rows a day from more than 20 power plants](https://www.tigerdata.com/case-studies/axpo) on Tiger Data’s Tiger Cloud, with performance holding up as connected systems multiplied. Tiger Data's positioning in this migration path is that it's still Postgres: existing SQL, tooling, and ORM code carries forward without a rewrite.
For each of these paths, the realistic first step is running the new system alongside the old one for a defined validation window before cutover. None of these are instant rip-and-replace migrations, and treating them as one increases risk without a corresponding benefit.