---
title: " Meter Data Management: AMI Interval Data Guide"
description: " See why legacy meter data management breaks under AMI interval reads, how VEE and exception queues work, and what a modern data layer needs."
section: "Postgres for IoT"
---
> **TimescaleDB is now Tiger Data.**
In utility and energy contexts, MDM means meter data management: the systems and processes that collect, validate, and process meter reads for billing. Legacy meter data management systems were built for monthly, scalar meter reads, one number per meter per month, collected by a human on a route or with a handheld scanner.
Advanced metering infrastructure (AMI) changed the input entirely. AMI meters report continuous interval reads, typically every 15 minutes or hourly, plus event data like outage pings and tamper flags. The systems built around the old data shape are now processing a workload they were never designed for, and that mismatch is the subject of this guide.
One disclosure up front: Tiger Data builds a Postgres database, available as the open-source TimescaleDB extension or as the managed Tiger Cloud service, and this guide points toward that architecture where it's genuinely the right fit. For the broader picture of how Tiger Data supports energy and utility workloads beyond this layer, see [Tiger Data for energy and utilities](https://www.tigerdata.com/energy-utilities).
This piece is a companion to Tiger Data's [Smart Grid Data Platform](https://www.tigerdata.com/learn/smart-grid-data-platform) guide, which covers the full four-data-type picture, SCADA, AMI, PMU, and DERMS, at overview depth. If you want that context first, start there. This guide picks up where the Smart Grid Data Platform guide leaves off and dives into:
- Why the AMR-to-AMI (automated meter reading to advanced metering infrastructure) data shape shift breaks legacy MDM,
- How VEE (validation, estimation, and editing) and the exception queue actually work,
- The governance gap trade press calls "AMI 2.0" and what a modern data layer needs to do about it.
## What changed: from AMR to AMI
Automated meter reading (AMR), the technology AMI replaced, produced one scalar read per meter per month, roughly 12 rows of data per meter per year. AMI changes the shape entirely: a meter reporting hourly generates 8,760 AMI interval reads per meter per year, and one reporting every 15 minutes generates 35,040, tens of thousands of rows per meter per year, before counting event data at all.
Scale that to a utility. Using the illustrative 100,000-endpoint utility from the Smart Grid Data Platform guide (a modeled example), hourly reporting alone produces roughly 2.4 million meter readings a day, close to 876 million a year. Under AMR, that same utility generated about 1.2 million reads a year total. That's several orders of magnitude of difference, and 15-minute intervals push the multiplier higher still.
That shift creates three specific pressures on any system built around AMR-era assumptions:
**Cardinality.** A schema designed for one row per meter per month wasn't built for a workload running orders of magnitude higher. Indexes and query plans that worked fine at AMR volume start to strain, then break, at AMI volume.
**Write pattern.** AMR systems wrote in batches, once a month. AMI systems have to absorb a continuous, high-frequency stream of writes, all day, with no natural lull to catch up during.
**Retention shape.** AMR-era systems rarely needed granular historical detail to stay queryable, because the monthly total was the unit of record. AMI detail stays operationally relevant long after it's written: a read from three months ago might still be pulled up for a billing dispute or regulatory audit.
None of this is simply old software needing an upgrade. It's a data-architecture problem. Swapping one legacy vendor for another built on a similar data model doesn't change the shape of the workload; it just changes who you're paying to struggle with it.
## Why legacy MDM breaks: VEE and the exception queue
Every MDM system, regardless of vendor, runs incoming meter reads through a process called VEE: validation, estimation, and editing. This is standard, vendor-neutral terminology across the industry.
**Validation** checks an incoming read against the account's expected consumption pattern; a read that's wildly out of range for that meter and season fails. **Estimation** fills in a statistically reasonable value when a read is missing or clearly invalid, so a gap in the data doesn't become a gap in the bill. **Editing** flags or corrects anomalies, often routing them to a person for a final decision rather than resolving them automatically.
Most legacy deployments run VEE downstream of a batch handoff. The AMI head-end system, which collects field reads, typically exchanges data with the MDM or billing system through batch file transfers rather than a continuous feed, a pattern that fit a monthly billing cycle but not one generating interval reads all day.
When a read fails VEE, it lands in an exception queue: a worklist needing human resolution before the billing cycle closes, usually through a field re-read, a manual correction, or a temporary hold on the bill. If it isn't resolved in time, the customer gets a delayed bill, or an estimated one that may need correcting once real data arrives.
Exception-queue volume scales with interval-read volume, not meter count. The illustrative utility above, generating roughly 2.4 million reads a day, creates vastly more opportunities for a read to fail validation than one generating a single monthly read. Legacy exception-handling throughput often wasn't designed for that scale, because it didn't need to be under AMR.
The downstream effect shows up in customer service. Billing-related disputes, incorrect reads, zero-usage bills, and uncorrected estimated bills are frequently cited in utility customer-service literature as a disproportionate driver of call volume, though the exact share varies by utility and isn't independently verified here. Directionally, it tracks: a backlogged exception queue produces more bills that need explaining after the fact.
## AMI 2.0 and the data governance gap
"AMI 2.0" is the term current energy trade press, POWER Magazine and Utility Dive among them, uses for the present wave of AMI upgrades. The framing is straightforward: AMI's data-volume growth outpaced the governance and architecture planning that should have accompanied it. Utilities deployed millions of AMI endpoints without rethinking the data platforms those endpoints feed into.
That gap produces a well-documented pattern: shadow IT. Business units unable to get what they need from the MDM or billing system stand up parallel data platforms that replicate AMI data for load forecasting, outage analysis, or DER planning. Each one solves a local problem. Collectively, they create a governance problem, since the same meter reads now exist in multiple places, potentially drifting out of sync.
The deeper issue here is data governance and architecture, not outdated software. A utility that swaps one MDM vendor for another without addressing why business units built their own data stores in the first place will likely see the same shadow IT pattern re-emerge a few years later.
## What an AMI data layer needs to do
Set aside vendor comparisons for a moment and ask what the data layer underneath AMI and billing actually has to do, scoped specifically to this workload:
- **Ingest high-cardinality interval data continuously, without loss,** at the write volumes described above, all day, not just at the end of a billing cycle.
- **Keep granular historical detail queryable,** not shipped to a cold, non-queryable archive, so exception review, audits, and regulatory lookback can reach a specific read months later.
- **Support VEE-adjacent query patterns directly in SQL.** Flagging a read outside a customer's expected consumption range is a query a modern database can express directly, rather than relying entirely on a proprietary rules engine.
- **Run billing-grade aggregation efficiently.** Rolling up interval reads into daily and monthly totals needs to be fast and consistent, not a nightly batch job that risks slipping past the billing cycle.
Three approaches show up in practice for handling this workload, and each has a real tradeoff:
| **Approach** | **What it is** | **Strengths** | **Limitations** |
| --- | --- | --- | --- |
| Enterprise MDM platform (e.g., Itron, Oracle Utilities, GE Vernova, Siemens Gridscale X, formerly EnergyIP) | Purpose-built billing, VEE, and rules-engine software | Mature regulatory and billing integrations; built-in VEE rules engines; vendor support | Older data models not built for AMI-scale cardinality; large-vendor deployments commonly run 12-18 months to go-live; exception throughput can lag read volume |
| Data historian | OT-native time-series store for process and telemetry data | Strong raw high-frequency ingest; native OT protocol support | Not built for billing logic, customer records, or VEE; a [data historian](https://www.tigerdata.com/learn/what-is-a-data-historian) isn't a substitute for MDM's billing function |
| Postgres + Tiger Data’s TimescaleDB (hypertables, continuous aggregates, columnstore compression) | General-purpose relational database extended for time-series workloads | SQL-native validation and anomaly queries; compression keeps years of data queryable; continuous aggregates precompute billing rollups | Doesn't replace a full MDM suite's compliance tooling or CIS integration; the data layer underneath VEE and billing, not a drop-in MDM replacement |
Tiger Data's fit here is specific: the data layer underneath VEE and billing-grade queries, not a wholesale MDM replacement. If your utility has heavy compliance requirements, working CIS integrations, and a vendor contract that's meeting your needs, a full enterprise MDM suite is still the right call, with Tiger Data (available in open source, cloud, and enterprise on-prem editions) handling the ingest and query workload underneath. For the analogous problem on the SCADA side, see [SCADA data management at scale](https://www.tigerdata.com/learn/scada-data-management-at-scale-architecture-historians-and-the-modern-database).
## Retention and compression for AMI-scale interval data
"Just archive the old interval data" doesn't hold up for this workload. Exception review, billing disputes, and regulatory audits require going back to a specific historical read, often months after the billing cycle closed. Data shipped to cold, non-queryable storage doesn't meet that bar; it's technically retained but practically inaccessible.
A more workable pattern keeps the current and prior billing cycle in an easily queryable hot tier for active exception review, then moves older AMI interval data into compressed storage that stays directly queryable via SQL, rather than a separate archive-and-restore process. Columnstore compression ([hypercore](https://www.tigerdata.com/docs/learn/columnar-storage/understand-hypercore)) is what makes this practical: years of interval-level detail stay compact and queryable, so a lookback from eight months ago requires a query, not a restore.
Exception review, audit response, and dispute resolution all depend on old data staying as reachable as recent data.
### Migrating from legacy MDM or file-based exception review
Utilities generally arrive here from one of three starting points: an aging on-premises MDM deployment nearing end-of-life or contract renewal, a spreadsheet- or file-based exception-review process that grew informally alongside a legacy system, or a shadow IT data platform, the kind described above, that a business unit built as a workaround and now wants consolidated.
What moves varies by starting point, but the pattern holds: raw interval-read ingest and VEE-adjacent query logic can move to a Postgres and Tiger Data layer, while regulatory compliance and CIS or billing integration typically stay with the existing system, at least initially. This is commonly a parallel run, not a rip-and-replace, the same pattern used for [historian-to-time-series-database transitions](https://www.tigerdata.com/learn/moving-past-legacy-systems-data-historian-vs-time-series-database) and in [Tiger Data's water utilities database guide](https://www.tigerdata.com/learn/water-utilities-database-how-to-store-query-scada-ami-quality-data-at-scale).
## Decision framework
### Choose an enterprise MDM platform (or stay with your current one) if:
- You need built-in regulatory compliance and rate-structure tooling out of the box.
- You have, or want, a single vendor-supported system that already integrates with your billing or CIS platform.
- Your exception-queue volume and interval-read scale are within what your current platform already handles without staffing strain.
### Choose a Postgres/Tiger Data-based data layer alongside your existing MDM or billing system if:
- Your exception-queue backlog is growing faster than your team can resolve it, and you suspect the underlying database, not the VEE rules themselves, is the bottleneck.
- You want to run VEE-style anomaly queries directly in SQL against full-resolution AMI interval data rather than waiting on a vendor's proprietary rules engine.
- You need years of interval-level detail to stay queryable for audit or dispute resolution, and your current retention approach ships old data to a non-queryable archive.
### Choose to keep things as they are, at least for now, if:
- Your utility's meter count and interval-read volume are modest enough that your current MDM platform isn't showing strain.
- You're mid-contract with an enterprise vendor, and a parallel migration isn't currently justified by the pain you're seeing.
- A large-scale MDM or data-layer change is a multi-month undertaking regardless of vendor, and it isn't the right call for every utility at every point in its AMI rollout.
The next guide in this series turns to DERMS and the challenge of unifying distributed energy resource data across systems.