The Data Foundation of Power & Utilities: A Reliable Walkthrough of Standards, Cloud, EDW, and Gartner Ratings

A distribution transformer just blew. The control room operator needs three things, fast: which customers hang off it, what its load was in the last 15 minutes, and whether the asset is still under warranty.

None of those three questions is hard on its own. The hard part is that the three answers live in three different systems — the network topology in GIS, the load reading in the MDMS (meter data management system), the asset record in ERP/EAM — and those three systems don't really talk to each other.

That's a normal Tuesday for utility data. It isn't a technical puzzle so much as a structural awkwardness: this industry is simultaneously ancient and cutting-edge, heavily regulated yet expected to respond in real time, still running last-century SCADA while drowning in hundreds of millions of smart-meter reads a day.

This piece has a narrow goal: to walk through the "data foundation of power and utilities" from a few angles — industry standards, the state of the EDW, cloud platforms, platform comparisons, and Gartner ratings. Because this space is full of fog — vendor marketing, self-anointed "Leaders," market-share numbers of dubious provenance — I gave myself one rule: every key claim gets a source, so it can be checked. The full link list is at the bottom.

Why utility data is hard by nature

Start with why utility data is special, because it underpins everything below.

It lives in three worlds at once. OT (operational technology — SCADA, EMS, protection relays), IT (billing CIS, ERP, customer service), and the IoT layer that exploded over the last decade (smart meters, sensors, distributed energy resources). Historically each of these ran on its own, with different data models, time resolutions, and security boundaries. Getting them onto one table is itself an engineering project.

Smart meters changed the order of magnitude. An AMI (advanced metering infrastructure) meter typically reports every 15 minutes — 96 data points a day. A utility serving 5 million customers generates close to half a billion meter reads per day from meters alone. And per the U.S. Energy Information Administration (EIA), the U.S. had roughly 119 million AMI meters installed by 2022, about 72% of all electric meters. That data flows to a data concentrator and then back to the MDMS. Traditional metering was one read per month; now it's 96 reads per day — three orders of magnitude apart.

It's also real-time, regulated, and safety-critical. The grid does sub-second fault detection and power-flow calculation, has to meet regulator reporting formats, and has to withstand attacks on critical infrastructure. So the data platform can't just chase "cheap and big" — it has to hold the line on latency, lineage, access control, and audit.

Add one variable you can't ignore in 2026: AI data centers are pushing electricity demand back up, which only deepens the grid's reliance on data for forecasting, dispatch, and asset management.

The three-layer world of utility data: OT, IT, and IoT converging into a unified data platform

Industry standards: IEC CIM and its extended family

If this space has a hard anchor — something that doesn't drift with vendor marketing — it's the standards. The power industry's standards stack is genuinely mature, and that's the single biggest thing separating it from oil & gas. Let's pin down the core.

IEC CIM (Common Information Model) is the shared semantics of power data. It isn't a product; it's a UML-based information model, plus a set of business-oriented interface "profiles," plus serialization rules for messages. It breaks into three big blocks:

Standard	Scope	Typical applications
IEC 61970	Transmission / grid operation & planning	EMS, SCADA, power-flow & optimization
IEC 61968	Distribution / operational support	DMS, outage management, metering, GIS, asset, CIS, ERP
IEC 62325	Electricity markets	Market settlement, trading information exchange

The value of CIM is that it gives systems that otherwise speak different dialects a common "grid vocabulary," consistent from generation through transmission and distribution all the way to markets.

CGMES is a hard example of CIM in production. It's the Common Grid Model Exchange Standard defined by ENTSO-E (the European network of transmission operators) — essentially a constrained profile of CIM, later adopted by the IEC as technical specifications IEC TS 61970-600-1 and 600-2 (2017). Per ENTSO-E, 42 TSOs across Europe use CGMES to exchange grid models, backed by a conformity-assessment process to ensure vendor implementations interoperate. That's the evidence the standard is actually running, not sitting on paper.

Moving toward distribution and the customer edge, there's a ring of standards each owning a slice — and understanding the division of labor matters:

Standard	What it covers	Who uses it
IEC 61850	Substation automation, real-time exchange, utility-scale DER	Substations, generation
IEEE 2030.5 (with the CSIP profile)	Small consumer-side DER (rooftop solar, storage, EVs)	DER interconnection (e.g., California)
OpenADR	Demand-response signaling (peak shaving, aggregation)	Dispatch & load aggregators
MultiSpeak	Enterprise app integration for distribution utilities (NRECA-led)	U.S. co-ops / smaller utilities
Green Button	Standardized export of customer energy-usage data	Consumer-facing

One thing to remember: these aren't mutually exclusive competitors but a layered collaboration. IEEE 2030.5, for instance, reuses parts of the IEC 61850 data model to describe DER components.

A useful contrast: oil & gas went a completely different way. Its unifying standard is the OSDU Data Platform, led by The Open Group, which folds in Energistics' WITSML/RESQML/PRODML and PPDM into one data ecosystem. Notably, the OSDU Data Platform Standard v1.0 was formally released in April 2026 — very recent news in the industry. If you touch both oil & gas and power, keep them straight: upstream oil & gas follows OSDU, the grid follows IEC CIM. Two standards, two worlds.

The state of the EDW: from Teradata and Oracle to a cloud lakehouse

Standards define what the data looks like; the EDW (enterprise data warehouse) decides where it lives and how it's computed. The utility EDW situation fits in one sentence: the legacy iron is still there, but the center of gravity is moving to a cloud lakehouse.

The legacy iron is usually some combination of Teradata, Oracle Exadata, IBM Db2, SQL Server — plus an MDMS stack around billing and metering. It's stable, but also expensive, hard to scale, and unfriendly to AI/ML and real-time analytics.

The migration direction is remarkably consistent: toward cloud-native platforms — Snowflake, Databricks (Delta Lake), BigQuery. The drivers are consistent too: high licensing and infrastructure cost, on-prem systems that don't scale elastically, AI/ML and real-time analytics that feel clunky on old platforms. Multiple migration write-ups boil the "forcing function" of 2026 down to one thing: AI-readiness. Almost every serious enterprise AI project — predictive maintenance, load forecasting, fine-tuning a model on proprietary data — demands high-quality, well-governed, accessible data, and the old EDW can't supply it.

There's a common and expensive trap worth calling out on its own: lifting Oracle or Teradata onto cloud VMs or managed databases as-is, with no refactoring. Multiple migration analyses note this lift-and-shift often increases cost rather than reducing it — potentially around 40% higher — because you carry inefficient schema design, unoptimized queries, and expensive stored procedures straight into an environment that bills by the second. The value of a migration is in the refactor, not the move.

From legacy EDW to a cloud lakehouse: the modernization path for the utility data stack

Cloud: how the three hyperscalers carve up the pie

Utilities have been putting real money into the cloud for a few years now. All three majors have built dedicated energy/utilities offerings, each with its own emphasis.

Snowflake launched Energy Solutions in January 2026, explicitly covering power, utilities, and oil & gas. The pitch is securely connecting IT, OT, and IoT data for predictive maintenance, grid optimization, and load forecasting. Publicly named customers include PG&E, Sunrun, IGS Energy, Powerex, and Siemens, alongside 30+ partner solutions and an SAP integration that brings SAP finance/supply-chain data together with field operations data on Snowflake.

AWS has a dedicated Energy & Utilities arm. A frequently cited deployment is Duke Energy working with AWS's machine-learning team to automate wooden-pole inspection with computer vision across roughly 33,000 miles of transmission lines — a very concrete "cloud + AI" example in utilities.

Azure has a strong presence in energy. Its Energy Data Services is built directly on the OSDU standard (serving mainly oil & gas), adopted by ExxonMobil, Chevron, Shell, and Equinor; Microsoft's $1B+ multi-year contract with ExxonMobil is one of the largest single cloud engagements in the energy sector. Note this part skews oil & gas — it's here to illustrate the scale of cloud investment in energy; on the power side, Azure has digital-grid offerings too.

Google Cloud leans on BigQuery's analytics and AI strength, and ranks furthest on the Vision axis in the latest Gartner evaluation (more on that below).

One honest caveat: the various "Cloud X holds Y% of the energy market" figures floating around mostly come from market-research firms, with uneven methodology and reliability. So this section deliberately leans on named customers and contracts — facts you can verify — rather than stacking up share percentages.

Platform comparison: Snowflake / Databricks / BigQuery in a power context

These three are the mainstream cloud-warehouse/lakehouse options. Their architectural philosophies genuinely differ, and the differences get amplified in a power context.

Dimension	Snowflake	Databricks	BigQuery
Architecture	Managed warehouse, separated storage/compute, no ops	Lakehouse; data in your own object storage, open format (Delta)	Fully serverless; just write SQL
Data format	Proprietary columnar; now also Iceberg	Open formats (Parquet/Delta), low lock-in	Proprietary, deeply integrated with GCP
Strengths	Multi-cloud, fast onboarding, great SQL analytics	AI/ML-native, unstructured data, unified batch + streaming	No tuning, event analytics, tight with Google AI
What it means for power	Billing/customer analytics, cross-system reporting, external data sharing	Massive meter time-series, predictive maintenance, model training	Quick-start analytics, real-time insight inside the Google stack

A rough rule of thumb: if your center of gravity is structured analytics like billing, customer, and regulatory reporting, plus cross-system and external data sharing, Snowflake usually feels smoothest; if it's massive smart-meter time-series that you want to train models on directly, Databricks' lakehouse fits better; if you want the lowest-ops starting point and you're already in the Google ecosystem, BigQuery is easy. Worth noting: these three keep converging — Snowflake now supports open Iceberg tables too, so the boundaries are blurrier than they used to be.

How to read Gartner ratings (and how not to get played)

You asked specifically about Gartner ratings and interpretation, so I put this last on purpose — it's the part most easily misused.

First, the newest and hardest facts. The Gartner evaluation most relevant to power data platforms is the Magic Quadrant for Cloud Database Management Systems, whose latest edition was published on November 18, 2025, assessing about 20 vendors. The 9 Leaders in this edition are:

AWS, Google, Microsoft, Oracle, Snowflake, Databricks, MongoDB, IBM, and Alibaba Cloud.

A few verifiable details: AWS is a Leader for the 11th consecutive year and is positioned highest of all vendors on Ability to Execute; Google is a Leader for the 6th year running and furthest on Completeness of Vision; Databricks is a Leader for the 5th year and scores top on the Lakehouse use case; and Teradata dropped to the Visionaries quadrant in this edition — which lines up neatly with the previous section's "center of gravity moving off the old EDW."

Beyond that main chart, two Gartner reports tie directly to power:

Hype Cycle for Digital Grid, 2025: key technologies include digital twins, AI/ML, and grid-edge intelligence; microgrids are placed in the "Early Mainstream" phase, at roughly 5%–20% market penetration.
Top Power and Utilities Trends for 2025: published January 2025, on the digital value propositions and resource orchestration facing utility CIOs.

Now the "how to read it" — which matters more than the rankings themselves:

Don't just stare at the top-right. The Magic Quadrant's two axes are Ability to Execute and Completeness of Vision, with Leaders in the top-right. But "Leader" doesn't mean "best for you." A Visionary that's stronger on your specific use case (say, massive time-series, or electricity-market settlement) may fit better than an all-rounder Leader.
Read it alongside the Critical Capabilities. The Magic Quadrant gives overall positioning; Gartner's Critical Capabilities reports score vendors by specific use case (analytical, operational, lakehouse, etc.). For selection, that's the more informative document.
Beware vendor cherry-picking. Most "we were named a Leader" posts you see online are vendors who licensed the report and quote only the part that flatters them. From the same report, everyone can find their own highlight. Gartner itself repeatedly stresses that ratings must be read in the context of the entire report — a single pulled quote means little.
Remember it's paid and time-stamped. The full Magic Quadrant sits behind Gartner's paywall, and the rankings shift yearly (Teradata's slide is the example). When you cite it, always include the edition year and publication date — otherwise "Gartner says" becomes an unverifiable line.

Bringing it down to earth: if you do data at a utility

Pulling it together, here's a framework you can use directly:

Know the standard before you pick the platform. The de facto standard on the grid side is the IEC CIM family (transmission 61970, distribution 61968, markets 62325), with CGMES on top for European interconnection. Platforms can be swapped; the semantic model is the foundation. Don't let a vendor's proprietary model lock down your data semantics.
For EDW modernization, refactor before you relocate. Moving from Teradata/Oracle to a lakehouse is the trend, but a straight lift-and-shift can easily cost more. Treat it as a chance to redesign schema, governance, and lineage — not as moving boxes.
Choose the engine by data shape, not by ranking. Structured reporting/billing/external sharing leans Snowflake; smart-meter time-series plus model training leans Databricks; lowest-ops start plus Google ecosystem leans BigQuery. Let the use case decide.
Treat OT/IT/IoT convergence as a first-class problem. The real difficulty of utility data isn't any single system but the seams between the three layers — which is exactly why this round of energy offerings from Snowflake, AWS, and Azure all lead with "connecting IT/OT/IoT."
Read Gartner with the year, by use case, and against the marketing. Treat the Magic Quadrant as a map, not scripture; for real selection, open its Critical Capabilities, and always go back to the source report.

There's no silver bullet for the utility data foundation. But it has something other industries envy: a mature, running, checkable body of standards. Anchor on the standards, treat platforms as tools, treat ratings as reference — keep that order straight, and you won't go too far wrong.

Sources (each claim can be checked against these):