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

Smart Grid Data Platform: Architecting for SCADA, AMI, PMU, and DERMS Data at Scale

By Tiger Data Team

Updated at Aug 5, 2026

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.

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 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 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 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.

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 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 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 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 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 or 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 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 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 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.

FAQ

What is DERMS?

DERMS stands for Distributed Energy Resource Management System, software that coordinates and dispatches signals to distributed assets like batteries, solar inverters, and EV chargers in near-real-time.

What database should I use for DERMS and distributed energy resource management?

The core requirements are high-frequency multi-source ingest, SQL-based cross-system queries, and hot/cold retention. A general-purpose time-series database on PostgreSQL is one path utilities and DERMS software vendors, including Plexigrid, have taken for the data layer, used alongside the specialized DERMS coordination software itself rather than in place of it.

What's the difference between DERMS and ADMS?

DERMS coordinates distributed energy resources specifically: batteries, solar inverters, and EV chargers. ADMS (Advanced Distribution Management System) manages the broader distribution grid, including switching and outage management. The two increasingly need to share data with each other even though they serve different functions.

Is DERMS becoming as important as SCADA for grid operations?

Industry coverage increasingly frames DERMS as operationally co-equal to SCADA, reflecting how much distributed generation and storage now needs active coordination. Treat it as a directional trend worth planning for, not a settled universal fact for every utility.

What's the difference between a data historian and a database for grid telemetry?

A data historian is a proprietary, OT-focused system built for single-domain time-series capture with limited SQL access. A general-purpose time-series database adds standard SQL querying, cross-domain joins, and more flexible retention and compression options.

Why doesn't legacy MDM handle smart meter interval data well?

Legacy MDM systems were built for monthly, AMR-era scalar meter reads, not AMI's continuous interval data. Many deployments bolt a modern AMI head-end onto a decades-old billing system via batch file exchange, which creates exception queues that grow every billing cycle.

How long does an MDM implementation take?

Large-vendor MDM deployments commonly take 12 to 18 months from contract to go-live. That's a current industry figure reflecting typical integration complexity.

How do utilities unify DER data from multiple systems (a "single source of DER data")?

The common pattern is three steps: identify the relevant datasets across meters, sensors, and DERMS or vendor platforms; standardize and de-duplicate the attributes across those sources; and structure the result so it's ready for downstream DERMS coordination. Separately, who can access and share distributed energy resource data across organizational and system boundaries is an evolving regulatory and standards question in the utility industry, distinct from the technical data-unification pattern.

How much data does a utility-scale PMU deployment generate?

A typical commercial PMU reports up to 120 measurements per second. A large utility PMU network can generate on the order of a terabyte of data per month. Treat that as a directional reference point, since deployment size varies significantly by utility.

Is PMU/synchrophasor data primarily a storage problem?

No. The harder constraint is transmission bandwidth to the control center and real-time processing under load. Storage and compression are the more solvable half of the problem.

Are utility data silos a technology problem or an organizational one?

Both. Unifying the data layer addresses the technical half, but teams pursuing the same reliability goals at the same utility often don't share data even when nothing technical prevents it, and that half requires organizational change rather than new infrastructure. Separately, who can access and share distributed energy resource data across a utility's systems and partners is an evolving regulatory and standards question industry-wide.

What's the difference between AMI and SCADA data?

AMI (advanced metering infrastructure) data is interval consumption and event data from customer-facing smart meters, typically on a 15-minute-to-hourly cadence. SCADA data is real-time operational telemetry (voltage, current, breaker status) from substations and feeders, typically polled on a seconds-to-minutes cadence. Both increasingly need to live in the same queryable data layer for cross-domain analysis.