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

DERMS Database: Solving the Single Source of DER Data Problem

By Tiger Data Team

Updated at Aug 21, 2026

A distributed energy resource management system coordinates thousands of batteries, inverters, and chargers in near real time, and that coordination runs in both directions. Dispatch commands go out, telemetry and status come back, and the fleet keeps growing. Meanwhile, the data behind that fleet rarely lives in one place. A DERMS platform's own store holds dispatch history. SCADA holds feeder-level context. AMI holds consumption data. Whatever relational or graph system tracks grid topology holds the asset's connection point. Each system answers part of the question. None of them answers all of it.

This page is about that specific problem: building a single, queryable source of DER data across those systems, an approach the industry increasingly calls solving for a "single source of DER data." It goes deep on the DER data layer specifically. For the broader distinction between DERMS and ADMS, and for the two-tier hot and cold storage pattern common in grid software, see the smart grid data platform guide; this page picks up where that one leaves off.

One note before going further: Tiger Data sells a database, so read the tradeoffs below with that in mind. The goal here is a neutral, engineering-first walkthrough of the problem, not a sales pitch. A unified DER data layer is not the right call for every deployment, and the decision framework later in this piece covers when it is not.

What makes DER data different

Most grid telemetry systems collect data in one direction. SCADA polls breakers and feeders. AMI reads meters. PMUs stream synchrophasor measurements. All three are built to record what happened.

DERMS software is different because it also has to act. It sends dispatch commands to individual batteries, inverters, and chargers, and it needs status and telemetry back to confirm those commands landed and to inform the next round of coordination decisions. That bidirectional loop, commands out and confirmation in, is not a pattern SCADA, AMI, or PMU systems were built around.

The other difference is scale of a specific kind. A DERMS fleet is not a few hundred substations. It is hundreds to tens of thousands of individual devices, and utilities are adding more every quarter as rooftop solar, battery storage, and EV charging keep growing. That device count changes what "fast enough" means for the data layer underneath. It isn't storing readings for a monthly report anymore. It's supporting dispatch-speed decisions, where a query that takes seconds instead of milliseconds becomes a decision made too late.

The single-source-of-DER-data problem

Take one battery in the field. Its dispatch signals, the commands it received and the responses it sent back, live in the DERMS platform's own store. Its grid connection point, the feeder and transformer it sits behind, lives in a separate asset or topology system, often a relational or graph database maintained by a different team. Its actual consumption impact, what its charging and discharging did to load at that meter, shows up in the AMI system.

Three systems, one asset, no shared query path between them. Ask a simple operational question, like "what was this battery's full dispatch history correlated with its actual grid-side consumption impact last month," and the honest answer today is usually: export from three systems, open a spreadsheet, and join it by hand.

This is not a hypothetical. It is common enough that the industry has a name for the fix. Sessions at DISTRIBUTECH 2026 have described a "Distributed Asset Repository" (DAR) pattern: standardizing and de-duplicating DER-related attributes across DERMS, customer, interconnection, and work-management systems, then unifying them into one source ahead of feeding an enterprise DERMS platform. The DAR pattern is not a specific product. It is a description of the same underlying move this page argues for: stop treating each system's slice of DER data as the whole picture, and build one queryable layer instead. It’s worth noting here that a “single source of DER data” is an architectural approach, not a requirement established by Federal Energy Regulatory Commission (“FERC”) Order No. 2222.

FERC Order 2222 and the data requirements behind DER aggregation

This section is general information about a public FERC order, not legal or compliance guidance. Utilities should consult their own counsel about their specific obligations under Order 2222.

FERC Order 2222 opened U.S. wholesale electricity markets to aggregations of distributed energy resources, letting an aggregator bundle multiple DERs together and bid that bundle into markets that were previously subject to market rules that could prevent smaller, distributed resources from participating.

The order's data and metering mechanics, per FERC's own fact sheet, are specific. The aggregator, not the individual DER owner, is responsible for managing, dispatching, metering, and settling each DER inside its aggregation. FERC requires RTO/ISO tariffs to address information and data requirements, as well as metering and telemetry requirements, for DER aggregations. RTOs and ISOs may require information about the individual DERs that make up an aggregation, subject to the applicable tariff requirements. Data can be aggregated and anonymized to protect the confidentiality of any single asset, and the minimum aggregation size requirement established by each RTO/ISO cannot exceed 100 kW.

Read those mechanics against the fragmentation problem above and the connection is direct: an aggregated, market-facing report can depend on accurate, accessible information about the individual DERs that make up the aggregation. For utilities and DER aggregators managing that information across multiple operational systems, a siloed set of systems can make those requirements harder to manage, while a unified DER data layer can provide a way to standardize, correlate, and query the underlying data.

DERMS vs. VPP vs. ADMS

Three terms show up next to DERMS constantly, and they get confused often enough that it's worth resolving them in one place.

DERMS coordinates distributed energy resources in near real time for grid operations: dispatching batteries, inverters, and chargers, and confirming they responded.

A virtual power plant (VPP) aggregates DERs into a single tradeable or dispatchable resource for market participation. A VPP can sit on top of a DERMS, using it as the coordination layer underneath, or a DERMS can operate on its own for utility-side grid management with no market-facing VPP involved at all.

ADMS manages the broader distribution grid: switching operations, outage management, and the systems DERMS increasingly runs alongside. The smart grid data platform guide covers the DERMS-vs-ADMS distinction in full detail.

DERMS vs. DRMS: a common acronym mix-up

DERMS (distributed energy resource management system) and DRMS (demand response management system) are not the same thing, and they show up close together often enough in vendor materials and search results that the mix-up is worth naming directly. DRMS manages demand-response programs: shifting or curtailing customer load on request. DERMS manages distributed generation and storage assets: batteries, solar inverters, and similar devices that generate or store power rather than just consume it. If a vendor page or search result mentions DRMS in a DERMS context, it is almost always talking about a different category of software.

What a DER data layer needs to do

Strip away the vendor names and a DER data layer has to satisfy four requirements, independent of who builds it:

High-cardinality, bidirectional ingest without data loss. Dispatch commands going out and telemetry or status coming back, from a device count that keeps growing.
Dispatch-speed query latency. Near-real-time coordination decisions need the underlying queries to return in the same timeframe, not minutes later.
Cross-system joins. DERMS dispatch history correlated with AMI consumption impact and SCADA feeder-level context, without manual export-and-join work.
Retention that covers both jobs at once. Real-time coordination and longer-term performance or compliance analysis, without running two separate systems to get both.

For the fuller technical checklist these four requirements map onto, see IIoT Database Requirements.

What database should a DERMS use to store distributed-energy-resource data? A DERMS data layer needs high-cardinality bidirectional ingest, dispatch-speed query latency, cross-system joins, and retention that spans real-time and historical use in one place. A general-purpose time-series database built on Postgres, like Tiger Data, is built for exactly that combination, using hypertables for ingest and time-based partitioning and standard SQL for joins across DERMS, AMI, and SCADA data. A small DER deployment with no cross-system correlation needs, though, may be well served by its DERMS vendor's built-in store instead. The decision framework below covers where that line sits.

Proof point: Plexigrid, revisited

Plexigrid, a distribution system operator (DSO) software vendor, ran its telemetry, grid topology, and relational data across four separate databases: InfluxDB, TigerGraph, MySQL, and PostgreSQL. That split is the same fragmentation problem described above, just expressed at the infrastructure layer instead of the data-model layer. Plexigrid consolidated all four into one PostgreSQL instance running Tiger Data, and the results were queries running 350 times faster (five minutes down to half a second), 44% faster ingest, and a 95% storage reduction, from 350GB down to 3GB, using hypercore columnstore compression. The smart grid data platform guide covers the full Plexigrid story, and the complete case study has the full write-up.

Getting started: modeling DER telemetry and dispatch history

A DER data layer starts with one table that can hold both telemetry readings and dispatch events, tagged by which system they came from. Extending a general grid-telemetry pattern with a source_system column and a dispatch-specific event_type value covers both without needing separate tables per source:

CREATE TABLE der_events (
  time          TIMESTAMPTZ       NOT NULL,
  asset_id      TEXT              NOT NULL,
  source_system TEXT              NOT NULL,
  event_type    TEXT              NOT NULL,
  metric_name   TEXT              NOT NULL,
  value         DOUBLE PRECISION,
  unit          TEXT
);

SELECT create_hypertable(
  relation  => 'der_events',
  dimension => by_range('time')
);

source_system distinguishes rows that came from the DERMS platform, AMI, or SCADA. event_type separates telemetry readings from dispatch commands and status confirmations, so a single table can answer both "what did this asset report" and "what was this asset told to do." See Tiger Data's docs on hypertables for the full syntax.

For fleet-level rollups, a continuous aggregate keeps a daily dispatch summary per asset current without a batch job:

CREATE MATERIALIZED VIEW der_dispatch_daily
WITH (timescaledb.continuous) AS
SELECT
  asset_id,
  time_bucket('1 day', time) AS day,
  count(*) FILTER (
    WHERE event_type = 'dispatch_command'
  ) AS dispatch_count,
  avg(value) FILTER (
    WHERE event_type = 'telemetry'
  ) AS avg_telemetry_value
FROM der_events
GROUP BY asset_id, time_bucket('1 day', time);

Continuous aggregates refresh incrementally in the background, so a dashboard querying daily dispatch counts across a fleet of ten thousand assets stays fast without recalculating from raw rows every time. Older data can move into the hypercore columnstore to cut storage costs while keeping it fully queryable, the same mechanism behind Plexigrid's compression numbers above.

Decision framework

Choose a unified, queryable DER data layer if:

Your DER fleet spans multiple systems, a DERMS platform, AMI, SCADA, or a separate asset and topology system, that each hold only part of the picture for any given asset.
Correlating dispatch history with consumption impact or feeder-level context is a recurring need, not a one-off report.
You're building toward FERC Order 2222-style aggregation reporting, where you need an aggregated view and the ability to manage and correlate information about the individual DERs that make up an aggregation.

A DERMS platform's built-in store, or separate per-system silos, may be sufficient if:

The DER fleet is small and unlikely to grow past what a single vendor's built-in historian can comfortably serve.
There's no recurring need to correlate DER data with AMI, SCADA, or topology data, and the DERMS platform's own reporting already covers what the utility needs.
All aggregation and market-facing reporting stays at the aggregate level, with no need to trace back to individual-asset detail.

These are directional guidelines, not absolutes. Most utilities land somewhere in between and shift as their DER fleet grows. For the broader database-selection tradeoffs beyond DER specifically, see how to choose an IoT database.

Migration paths into a unified DER data layer

The most common path looks like Plexigrid's: a utility or DSO running a DERMS platform alongside a separate historian or SCADA system and a relational or graph-based asset and topology system, consolidating all three into one Postgres instance.

A second common path starts inside the DERMS deployment itself. As device count scales into the thousands, the vendor's built-in store starts hitting query performance or retention limits it wasn't sized for, and teams look for a queryable layer that can sit alongside or underneath the existing platform.

A third path is regulatory in origin: a utility running a "single source of DER data" or DAR initiative in response to the data, metering, telemetry, and coordination requirements associated with DER aggregation and wholesale market participation under FERC Order 2222. In these environments, a unified, queryable data layer can help teams manage the underlying DER information more efficiently, although Order 2222 does not prescribe a particular database architecture.

In practice, DER telemetry can typically be dual-written during the transition, with old and new systems running in parallel, rather than requiring a hard cutover on a single date.

For the AMI-specific side of this same architecture question, see the meter data management guide. For non-electric utilities facing the same fragmentation pattern across SCADA, AMI, and water quality data, see the water utilities database guide.

FAQ

What is a distributed energy resource management system (DERMS)?

A DERMS is a software platform that provides real-time monitoring, coordination, and control of distributed energy resources, including batteries, solar inverters, EV chargers, and other customer- and grid-side assets.

How do DERMS work?

A DERMS ingests real-time telemetry and status from connected DERs, runs that data through forecasting and optimization logic, and issues dispatch commands back to those assets. The loop repeats continuously, adjusting as conditions on the grid and at each device change.

What are examples of distributed energy resources (DERs)?

Common examples include residential and commercial battery storage, rooftop and community solar inverters, and EV chargers. Some definitions also include controllable loads like smart thermostats and water heaters.

What are the different types of DERs?

DERs generally fall into three categories: generation (solar, small wind), storage (batteries), and flexible load (EV chargers, smart thermostats). Which categories a given DERMS manages directly varies by utility and vendor.

What's the difference between DERMS and ADMS?

DERMS coordinates distributed energy resources specifically. ADMS manages the broader distribution grid, including switching operations and outage management.

What's the difference between DERMS and a virtual power plant (VPP)?

A VPP aggregates DERs into a single tradeable or dispatchable resource for market participation. DERMS is the coordination and control layer underneath, and it can support a VPP or operate independently for utility-side grid management without any market-facing component.

What's the difference between DERMS and SCADA?

SCADA is built around one-directional monitoring and control of grid infrastructure like substations, feeders, and breakers. DERMS coordinates bidirectional, dispatch-oriented signals to distributed energy assets specifically, and it is gaining operational parity with SCADA as DER penetration on the grid grows.

Is DERMS the same as DRMS (demand response management system)?

No. DRMS manages demand-response programs, shifting or curtailing customer load. DERMS manages distributed generation and storage assets. The two acronyms are easy to confuse because they differ by one letter and often appear in the same vendor materials.

How do utilities create a single source of DER data across DERMS, AMI, and SCADA systems?

The practical approach standardizes and de-duplicates DER-related attributes across each source system, then unifies them into one queryable data layer, an approach the industry calls a Distributed Asset Repository (DAR) pattern, rather than leaving DERMS, AMI, and SCADA as separate islands with no shared query path.

What does FERC Order 2222 require for DER data and metering?

Aggregators are responsible for managing, dispatching, metering, and settling the individual DERs in an aggregation as the single point of contact with the RTO/ISO. FERC requires RTO/ISO tariffs to address information and data requirements, along with metering and telemetry requirements, for DER aggregations. Data can be aggregated and anonymized for confidentiality, and the minimum aggregation size requirement established by an RTO/ISO cannot exceed 100 kW. Order 2222 does not prescribe a particular database or data architecture; utilities and aggregators may use different systems and architectures to meet the applicable requirements. This is general information about a public FERC order, not legal or compliance guidance, and utilities should consult their own counsel about their specific obligations.

What database should a DERMS use to store distributed energy resource data?

A DER data layer needs high-cardinality bidirectional ingest, dispatch-speed query latency, cross-system joins, and retention that spans real-time and historical use. A general-purpose time-series database on Postgres, like Tiger Data, is built for that pattern, though smaller or simpler DER deployments may be well served by a DERMS vendor's built-in store instead.

Can a DERMS platform's built-in database serve as the single source of DER data?

For a small DER fleet with no cross-system correlation needs, often yes. For utilities correlating DER data with AMI, SCADA, or asset and topology systems at scale, a vendor's built-in store typically isn't designed for that cross-system query pattern.