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

Meter Data Management: Why AMI Interval Data Breaks Legacy MDM Systems

Meter Data Management: AMI Interval Data Guide

By Tiger Data Team

Updated at Aug 10, 2026

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.

This piece is a companion to Tiger Data's 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 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.

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) 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 and in Tiger Data's water utilities database guide.

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.

FAQ

What does MDM mean in a utility context, meter data management or master data management?

In utility and energy contexts, MDM almost always means meter data management, the systems and processes that collect, validate, and process meter reads for billing. In broader enterprise-software search, however, MDM more commonly refers to master data management, an unrelated data-governance discipline. If you're researching utility metering software, look for the fully spelled-out term to confirm you're in the right category.

Why doesn't legacy MDM handle AMI interval data well?

Most legacy MDM systems were designed around AMR-era metering: one scalar read per meter per month, exchanged in batch. AMI generates continuous 15-minute or hourly interval reads plus event data, orders of magnitude more rows per meter per year. The resulting cardinality, write frequency, and retention needs exceed what those systems' underlying data models were built to handle.

What is VEE (validation, estimation, and editing) in meter data management?

VEE is the standard three-step process MDM systems use to process incoming meter reads: validation checks a read against expected consumption patterns, estimation fills in a statistically reasonable value when a read is missing or clearly invalid, and editing flags or corrects anomalies, often routing them for human review.

What happens when a meter read fails VEE and lands in the exception queue?

A read that fails validation gets routed to an exception queue, where a team resolves it, commonly through a field re-read, a manual correction, or a temporary billing hold. If it isn't resolved before the billing cycle closes, the customer either receives a delayed bill or an estimated one that may require a later correction.

What is AMI 2.0, and how is it different from the first wave of smart meter rollouts?

AMI 2.0 is current trade-press shorthand for the present wave of AMI upgrades, distinguished from earlier rollouts by its focus on data governance and architecture rather than hardware. The core argument in current industry coverage is that AMI's data-volume growth outpaced the governance planning and architecture changes that should have accompanied it, leading some utilities to build informal 'shadow IT' data platforms as a workaround.

How long does a meter data management system implementation take?

It depends heavily on scale and vendor. Large enterprise-vendor deployments (Itron, Oracle Utilities, Siemens-scale platforms) commonly run 12-18 months from contract to go-live. Smaller MDM platforms marketed toward utilities with fewer meters have claimed materially faster timelines in the 12-24 week range.

What's the difference between a data historian and a database for meter/AMI data?

A data historian is purpose-built for OT/process telemetry, high-frequency sensor and control-system data, typically with native industrial-protocol connectors. It isn't designed for billing logic, customer records, or VEE workflows. A general-purpose time-series-capable database like Postgres with Tiger Data can sit underneath both AMI interval ingest and VEE-style query logic, but it doesn't replace a historian's OT-specific connectivity or a full MDM suite's billing/regulatory tooling on its own.

What is the best database for storing and querying smart meter (AMI) interval data?

The right choice depends on scale and workload. For high-frequency interval ingest that needs to stay queryable for years (for exception review, billing rollups, and audit lookback), a relational database extended for time-series workloads, such as Postgres with Tiger Data's hypertables, continuous aggregates, and columnstore compression, handles the cardinality and retention needs directly in SQL. It sits underneath, rather than replaces, an enterprise MDM suite's regulatory and billing-integration tooling.

How much interval data does a mid-size utility generate from AMI meters?

As an illustrative example: a utility with 100,000 AMI endpoints reporting hourly generates roughly 2.4 million meter readings per day. Utilities with 15-minute interval reads or larger endpoint counts scale proportionally higher.

Can a general-purpose database like Postgres replace an enterprise MDM platform?

Not wholesale. Postgres extended with Tiger Data can handle the high-cardinality ingest, VEE-adjacent anomaly queries, and billing-grade aggregation that legacy MDM data models struggle with, but it doesn't include an enterprise MDM suite's built-in regulatory compliance tooling or CIS/billing integrations. Utilities most often run it as the data layer underneath their existing MDM or billing system, not as a full replacement.

How should utilities structure retention for AMI interval data to stay both compliant and queryable?

A common pattern keeps the current and prior billing cycle in an easily queryable hot tier for active exception review, then moves older interval data into compressed storage that remains directly queryable via SQL, rather than shipping it to a cold, non-queryable archive. This keeps years of interval-level detail available for regulatory audits and billing disputes without a separate restore process.

Is 'interval data' always the same thing as AMI smart-meter data?

No. 'Interval data' is a general term that also applies to unrelated statistical and measurement contexts. In a utility/AMI context, it specifically means the time-stamped, repeating-interval meter reads (e.g., every 15 minutes or hourly) that smart meters generate, distinct from the older monthly scalar reads that AMR-era meters produced.