---
title: "DERMS Database: Single Source of DER Data"
description: "Unify fragmented DER data across DERMS, AMI, and SCADA into one queryable Postgres database. See the architecture, schema, and decision framework. "
section: "Postgres for IoT"
published: 2026-09-06T15:03:23.552Z
updated: 2026-08-21T00:00:00.000Z
---
*Updated at Aug 21, 2026*
> **TimescaleDB is now Tiger Data.**
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](https://www.tigerdata.com/learn/smart-grid-data-platform); 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](https://docs.google.com/document/d/1W4kyuMKg26XyWJUV-VCrBUdwr7qjN1Vp0wgw036E-Bw/edit#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](https://www.tigerdata.com/learn/scada-data-management-at-scale-architecture-historians-and-the-modern-database). 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](https://www.ferc.gov/media/ferc-order-no-2222-fact-sheet) 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](https://www.ferc.gov/media/ferc-order-no-2222-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](https://www.tigerdata.com/learn/smart-grid-data-platform) 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](https://www.tigerdata.com/learn/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](https://docs.google.com/document/d/1W4kyuMKg26XyWJUV-VCrBUdwr7qjN1Vp0wgw036E-Bw/edit#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](https://www.tigerdata.com/learn/smart-grid-data-platform) covers the full Plexigrid story, and the [complete case study](https://www.tigerdata.com/blog/from-4-databases-to-1-how-plexigrid-replaced-influxdb-got-350x-faster-queries-tiger-data) 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](https://www.tigerdata.com/docs/reference/timescaledb/hypertables/create_hypertable) 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](https://www.tigerdata.com/docs/learn/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](https://www.tigerdata.com/docs/learn/columnar-storage/understand-hypercore) 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](https://www.tigerdata.com/learn/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](https://www.tigerdata.com/learn/meter-data-management-ami-database). For non-electric utilities facing the same fragmentation pattern across SCADA, AMI, and water quality data, see the [water utilities database guide](https://www.tigerdata.com/learn/water-utilities-database-how-to-store-query-scada-ami-quality-data-at-scale).