---
title: "Grid Modernization: The Data Layer Problem"
description: " Grid modernization means unifying SCADA, AMI, PMU, and DERMS data. See why the data layer, not more hardware, decides if it pays off. "
section: "Postgres for IoT"
published: 2026-09-18T20:02:36.566Z
updated: 2026-09-18T00:00:00.000Z
---
*Updated at Sep 18, 2026*
> **TimescaleDB is now Tiger Data.**
Utilities are on pace to spend roughly $5.8 trillion on grid modernization globally between 2026 and 2035. Most of that money is going toward hardware: smart meters, sensors, switches, substation upgrades. Less is going toward the systems that turn what those devices report into something a utility can actually query and act on. That gap is the subject of this guide.
## What does grid modernization actually mean?
**Grid modernization **is the process of applying digital sensing, communication, control, computing, and data-management systems to the electric grid, unifying data from SCADA, AMI, PMU, and DERMS into infrastructure that utilities can query, analyze, and act on in real time. The [U.S. Department of Energy](https://www.energy.gov/sites/default/files/2022-05/2020%20Smart%20Grid%20System%20Report_0.pdf) says the term itself "has no strict definition."
That's the thesis of this piece: the harder, less-discussed part of grid modernization isn't the hardware, it's the data layer underneath it. Utilities can deploy every smart meter and sensor on their roadmap and still lack a unified, queryable view of the grid, because the systems generating that data were never built to talk to each other.
Tiger Data is a Postgres-based database company, and this piece makes the case for a data-platform-first approach. When choosing your approach, weigh it against your own team's requirements and existing investments.
### Grid modernization vs. smart grid: are they the same thing?
Not quite. Grid modernization is the broader initiative: the overall program of applying digital technology to grid operations. A smart grid, one instrumented with two-way digital communication and automated control, is one outcome of it.
"Smart grid" is the term most consumers and industry press use day to day. Grid modernization describes the same underlying data problem, at the program level rather than the single-outcome level, and it's the term this guide uses throughout.
## The four systems behind a modern grid
A modernized grid depends on four telemetry systems, each built for a different job: SCADA (Supervisory Control and Data Acquisition) monitors and controls grid operations, AMI (Advanced Metering Infrastructure) captures customer-side metering, PMU/WAMS (Phasor Measurement Units / Wide-Area Monitoring Systems) capture high-frequency phase and frequency data to detect instability before it cascades, and DERMS (Distributed Energy Resource Management System) coordinates rooftop solar, batteries, EV chargers, and other grid-edge devices.
| **System** | **What it monitors** | **Typical data shape/frequency** | **Where this cluster covers it** |
| --- | --- | --- | --- |
| SCADA | Substations, breakers, transformers, grid operations | Discrete events and periodic polling, seconds to minutes | [Smart Grid Data Platform](https://www.tigerdata.com/learn/smart-grid-data-platform) and the [SCADA data management guide](https://www.tigerdata.com/learn/scada-data-management-at-scale-architecture-historians-and-the-modern-database) |
| AMI | Customer meters, consumption | Interval reads, every 15-60 minutes per meter | [Meter Data Management and AMI database architecture](https://www.tigerdata.com/learn/meter-data-management-ami-database) |
| PMU/WAMS | Phase angle, frequency, grid stability | Continuous high-frequency streams, up to 60+ samples/second | [Smart Grid Data Platform](https://www.tigerdata.com/learn/smart-grid-data-platform) |
| DERMS | Solar, batteries, EV chargers, grid-edge devices | Dispatch commands and telemetry, seconds to minutes | [DERMS Database](https://www.tigerdata.com/learn/derms-database) |
Here's the practical, everyday form the "grid modernization is a data problem" thesis takes: most utilities run all four as separate systems on separate databases, maintained by separate teams. SCADA lives in a historian, AMI in a meter data management (MDM) system, PMU data wherever the transmission operator's monitoring vendor put it, DERMS in whatever platform its aggregation vendor shipped. None were built to answer a question spanning more than one of them.
The mechanics behind each system, historian and Ignition-based OT integration on the SCADA side, exception queues and VEE on the AMI side, dispatch and aggregation on the DERMS side, are covered in the linked spokes above. This guide stays at the category level.
This fragmentation isn't unique to electric utilities, either. Water utilities run a similar mix of SCADA, AMI, and quality data across separate systems, covered in the [Water Utilities Database](https://www.tigerdata.com/learn/water-utilities-database-how-to-store-query-scada-ami-quality-data-at-scale) guide.
## Why data infrastructure, not hardware, is the real constraint
Most utility modernization plans read like hardware plans. Deploy smart meters. Install PMUs. Upgrade switches. That's necessary, but it's not the constraint that actually determines whether a modernization program pays off.
The AMI spoke in this cluster documents a pattern utilities are now calling "AMI 2.0": data volume from newly deployed meters and sensors has been outpacing the governance and architecture planning needed to make sense of it. Hardware gets funded and installed. The schema standards, query layer, and ownership model underneath it usually don't get the same budget.
The practical consequence: a utility can deploy every smart meter and PMU on its roadmap and still be unable to answer a basic cross-system question, like correlating a voltage event with nearby DER output at the same timestamp, if that data lives in four incompatible silos.
This isn't true of every utility, but industry coverage consistently points to it as a recurring pattern: hardware investment outpacing the data layer that would let a utility use what the hardware produces.
## Why now: the investment driving grid modernization
The scale of investment now underway makes this an urgent architecture question, not a theoretical one. [Global grid modernization investment is forecast](https://www.jpmorgan.com/insights/sustainability/climate/grid-resilience-neglected-no-more) at roughly $5.8 trillion between 2026 and 2035, with about $700 billion allocated specifically to digital grid technology. In the U.S. alone, utilities are expected to invest on the order of $1 trillion over the coming decade.
The defining trend shaping how that money gets spent is IT/OT/IIoT convergence: utilities moving toward connected sensors, asset-health monitoring, and real-time analytics for one unified view of operations, asset performance, and customer demand, rather than the siloed systems that have historically defined utility IT. Current trade press and industry research document this broadly.
As that spending mix shifts from pure hardware toward digital systems, the data infrastructure question becomes the deciding factor in whether the investment pays off. A utility that spends heavily on sensors and metering without a plan for the data layer underneath ends up with more raw telemetry and the same fragmented visibility it started with.
## The common architecture pattern behind modern grid data platforms
A consistent technical pattern is emerging for how utilities converge grid data. SCADA-side systems typically connect through OPC-UA, the industrial automation protocol most historians already speak. DERMS and IoT-side systems, including grid-edge devices and DER controllers, typically converge through MQTT, the lightweight protocol built for high device counts and intermittent connectivity.
Both paths feed into a common schema shape, regardless of which system originated the data:
| **Field** | **Description** |
| --- | --- |
| `device_id` | Unique identifier for the asset or meter generating the reading |
| `timestamp` | When the reading occurred, at source-system precision |
| `signal_type` | What's being measured (voltage, frequency, kWh, state of charge, breaker status) |
| `value` | The reading itself |
| `source_system` | Which system produced this record (SCADA, AMI, PMU, DERMS) |
That shape is deliberately simple, a common denominator rather than a full data model; each source system still carries additional fields specific to its domain. What matters is that a query layer built around this shape can join across all four systems without four separate integration projects.
This pattern matches what the [Smart Grid Data Platform](https://www.tigerdata.com/learn/smart-grid-data-platform) guide lays out at the platform level. Treat that guide as this cluster's primary architectural reference point if you're starting from scratch.
## The governance gap: where grid modernization projects stall
The AMI spoke in this series documents a governance gap specific to metering data: as interval reads outpace what legacy MDM systems can validate, the absence of a clear ownership model becomes the actual bottleneck, not any limitation in the meters themselves. That finding generalizes across the whole grid modernization picture: as more systems come online, the absence of a single ownership model, shared schema standard, or common query layer becomes the real blocker. A few concrete symptoms are worth checking yourself against:
- Analysts maintaining parallel exports from SCADA, AMI, and DERMS by hand, because no system can natively query across the others.
- No single source of truth for a given grid asset. The same transformer might carry three different IDs across three systems, with no reliable way to reconcile them.
- Dashboards that take days, not minutes, to update after a grid event, because someone has to manually pull and reconcile data before an analyst can start looking at what happened.
This isn't an argument that more systems are inherently bad; each earns its place for a real operational reason. But the coordination cost between them compounds as more come online, and eventually that cost, not any single system's limitations, becomes what stands between a utility and the cross-system visibility its investment was supposed to buy.
## Choosing a data platform for grid modernization
Once a utility recognizes the data layer as the actual constraint, the next question is what to build it on. This is a genuine tradeoff, and the answer depends on what's already deployed and what compliance requires.
**The case for Postgres and Tiger Data:** [Hypertables](https://www.tigerdata.com/docs/learn/hypertables/understand-hypertables) automatically partition time-series data so queries stay fast as telemetry accumulates. [Hypercore's columnstore compression](https://www.tigerdata.com/docs/learn/columnar-storage/understand-hypercore) keeps fast-accumulating PMU and AMI data affordable to store online instead of archived out of reach. [Continuous aggregates](https://www.tigerdata.com/docs/learn/continuous-aggregates) pre-compute rollups so dashboards stay fast without nightly batch jobs. Because it's still Postgres, you can join time-series telemetry with relational asset and customer data in standard SQL, a genuine differentiator against purpose-built historians and time-series databases, which typically require a separate relational store for that same context.
**The case for purpose-built historians and time-series databases:** These systems carry real strengths: products like the AVEVA PI System have deep native OT and SCADA integration built over decades, vendor certifications procurement may require, and years of hardening in pure OT environments. Teams already standardized on a historian for a single, well-scoped deployment often find switching costs outweigh consolidation's benefit, at least until a second system comes online.
Where Tiger Data isn't the best fit: a utility running a single, tightly scoped OT deployment with a hard vendor-certification requirement and no near-term plan to unify data across systems may not need a general-purpose platform. The case for consolidation gets stronger as more systems come online.
If AWS services come up in this comparison: [Timestream for LiveAnalytics stopped accepting new customers](https://aws.amazon.com/about-aws/whats-new/2025/05/aws-service-changes/) in June 2025 and isn't an available option. Timestream for InfluxDB is the product AWS continues to develop in that family.
## Decision framework: where should a utility start?
Utilities considering a modernization program often ask whether to start with hardware, software, or data infrastructure. The honest answer is that it depends on what's already deployed.
**Start with data infrastructure consolidation if:** two or more of SCADA, AMI, PMU, or DERMS are already deployed and generating data with no shared way to query across them, and cross-system analysis takes manual exports and days rather than minutes.
**Prioritize sensor and hardware deployment first if:** the data these systems would generate doesn't exist yet at meaningful scale. A data platform has nothing to unify until telemetry is being collected.
**Choose a Postgres-based platform like Tiger Data’s **[**Tiger Cloud**](https://www.tigerdata.com/cloud)** or **[**TimescaleDB Enterprise**](https://www.tigerdata.com/timescaledb-enterprise)** if:** your team already works in SQL and Postgres, you need to combine time-series telemetry with relational asset or customer data, or you want one platform serving SCADA, AMI, and DERMS rather than a separate tool per system.
**Choose a purpose-built historian or time-series database if:** you operate a single, narrowly scoped OT environment with a hard vendor-certification or compliance requirement a general-purpose database doesn't meet.
## Common migration paths into a unified grid data platform
**Consolidating multiple point solutions.** A utility running separate databases per system (a SCADA historian, an AMI/MDM store, a DERMS vendor's own database) migrates onto one platform to eliminate duplicate infrastructure and enable cross-system queries. [Plexigrid followed this path](https://www.tigerdata.com/blog/from-4-databases-to-1-how-plexigrid-replaced-influxdb-got-350x-faster-queries-tiger-data), consolidating four databases into one and cutting query times by up to 350x. The full story is also told on the [Smart Grid Data Platform](https://www.tigerdata.com/learn/smart-grid-data-platform) guide and revisited in the [DERMS Database](https://www.tigerdata.com/learn/derms-database) guide.
**Migrating off a legacy SCADA historian while OT systems stay in place.** Some utilities need to replace an aging historian without touching the OT layer feeding it. The [SCADA data management guide](https://www.tigerdata.com/learn/scada-data-management-at-scale-architecture-historians-and-the-modern-database) covers this migration pattern in depth.
**Extending an existing AMI/MDM deployment to absorb DERMS or PMU data.** Rather than standing up another isolated database per new system, utilities with a working AMI or MDM deployment can extend it to take on DERMS or PMU data as those systems come online.