The energy industry is absorbing an enormous amount of AI investment right now, and a lot of it is running into the same wall. Not a model quality problem. Not a data availability problem. An infrastructure problem - and it has two layers that don’t always get discussed together.
The first layer is physical. Data centers are scaling faster than the power systems and grids that support them. Utilities are being asked to forecast and stabilize load patterns that simply didn’t exist a few years ago, particularly under extreme weather conditions, and transmission, storage, and generation capacity critical to grid resilience aren’t keeping up with demand curves driven by AI workloads. This is already shaping where and how AI can realistically be deployed.
| 415 TWh | Global data centre electricity consumption in 2024 - projected to more than double to 945 TWh by 2030, growing 15% per year. AI-focused servers are the fastest-growing segment. |
The second layer is less visible and, in my experience, more immediately limiting for the teams actually trying to deploy AI in operations: most energy data architectures aren’t built to support the real-time, cross-system coordination that AI applications require in order to do anything useful.
You can close the generation gap and still not be able to run an effective AI-driven demand response loop, because the data layer connecting your systems can’t reconcile state fast enough to act on it. That’s the problem I want to focus on here.
The data is there. The coordination isn’t.
If you sit down with most utility or grid operations teams and ask whether they have enough data, the answer is usually some version of “too much.” Grid telemetry streams continuously. Weather models update in real time. Market signals shift by the minute. Asset-level data across generation, energy storage systems, and transmission is always in motion. On paper, the system has what it needs to make fast, accurate decisions.
The issue is that all of that data lives in systems that operate on different timelines and make different assumptions about what “current state” means. Your SCADA or EMS reflects device and network state as it is right now. Your analytical systems reflect recent history, typically after a pipeline has processed it. Your forecasting systems are projecting forward from inputs that are already slightly stale. Your market systems operate on their own cadence entirely.
Each layer is internally consistent. But they’re not synchronized with each other, and that gap means decisions lag behind reality by anywhere from minutes to hours.
Key insight: This isn’t a data quality problem, but a coordination one embedded in how the architecture was designed - at a time when “real time” meant same-day and most decisions were made by people rather than automated systems. |
What the gap looks like in practice: AMI at scale
Consider what a large utility is managing today across its advanced metering infrastructure. Millions of smart meters generating tens of thousands of readings per second in steady state, with burst spikes during major weather events. Weather feeds and forecasts. Real-time market prices and grid constraints. Asset data across feeders, transformers, distributed energy resources, and energy storage assets.
The global AMI (Advanced Metering Infrastructure) market tells the story: valued at $7.74 billion in 2024, it’s projected to reach $15.82 billion by 2032 - an 11.7% CAGR driven by smart grid investment and the push for real-time demand response capabilities. A typical AMI system generates over 3,000 data points per meter annually. The volume isn’t the problem. What you do with it is.
3,000 | Data points generated per meter annually in a typical AMI system. Utilities with millions of meters are managing billions of data points - most of it processed in batch cycles, not in real time. |
In a conventional architecture, that data moves through a familiar sequence: AMI head-ends and SCADA capture events; ETL or streaming jobs push subsets into a data lake or warehouse; aggregations run there; and operators, planners, and traders see outputs hours later, often through different tools running against different underlying states. Outage analytics, load studies, and theft detection typically run overnight.
That design made sense when the primary consumers of that data were human analysts and the tolerance for latency was measured in hours. Neither of those things is true anymore.
Consider what a near-real-time AMI-to-demand-response loop actually requires: a meter event arrives, it triggers a price signal, that signal fires a dispatch to a virtual power plant aggregate, and the whole sequence completes within the event window - not in the next batch cycle. Or consider an AI copilot for a control-room operator: if it’s grounding its responses in data from the last batch run, it’s not grounding them in the state the operator is actually looking at.
Real-world consequence: In July 2024, a voltage fluctuation in northern Virginia caused 60 data centres to simultaneously switch to backup generation - a sudden 1,500 MW swing that nearly triggered cascading outages. Grid stability and data latency are directly connected. |
These aren’t exotic use cases. They’re the use cases that justify the AI investment in the first place. And they fail when the architecture requires data to cross three or four systems before it’s usable, because every hop adds latency, operational risk, and the possibility that different systems are showing different versions of reality.
Do you have this problem?
You don’t need an architecture review to find out. A few direct questions are usually enough:
How many systems does data cross between the triggering event and the decision that acts on it?
When your operational, forecasting, and market systems disagree about current state - and they do, even if it’s not always visible - does anyone have a reliable way to detect it?
When a major grid event hits, are your most critical queries returning in seconds or minutes?
In the last two years, have you added more pipelines and sync jobs than you’ve been able to retire?
If those questions resonate: The problem isn’t data volume or quality in isolation. It’s an operational coordination problem baked into how the architecture moves data between systems. |
Why existing architectures hit a ceiling
Most energy data architectures follow a pattern that made a lot of sense for its original purpose: real-time systems capture operational signals; pipelines move that data into centralized stores; analytical systems process and aggregate; separate applications drive decisions from there. The pattern was designed for human-paced decision-making and off-peak analytical workloads.
AI-driven operations require something different in every one of those dimensions. Data freshness requirements tighten dramatically. Consistent state across systems goes from “nice to have” to operationally critical. Concurrency requirements shift - it’s not just human analysts hitting the system anymore, it’s control-room operators, market systems, automated workflows, and AI agents all querying live state simultaneously. And decision latency tolerance compresses from minutes or hours to seconds.
The underlying architecture still depends on moving data between systems before it can be used. Every movement introduces delay, duplication, and the possibility of inconsistency. At grid scale and AI workload volumes, those costs compound quickly.
$6.09B → $19.12B | Smart grid data analytics market growth projected by 2034 (12.1% CAGR). The investment is accelerating - but it only pays off if the underlying data architecture can support real-time decisions. |
What has to change
The architectural response to this problem is a structural shift away from loosely coupled data platforms toward what’s increasingly called an operational data system - a layer where ingestion, storage, processing, and serving are part of the same operational loop rather than a sequence of handoffs between specialized engines.
Concretely, this means a few things have to be true simultaneously:
Data movement needs to be minimized. Every extra hop adds latency and operational risk, and the more AI and automation you add, the more that tax shows up in performance.
Mixed workloads need to run natively on the same engine. Operational decisions blend transactions, analytics, and operational queries. If those live on separate systems, you’ve baked inconsistency into the design.
Concurrency requirements are higher than most analytical systems are tuned for. The combination of human operators, automated systems, and AI agents all hitting live state is fundamentally different from overnight BI workloads.
Historical context needs to be first-class. Decisions about whether a load pattern is normal, or what happened the last ten times conditions looked like this, require time-series and historical joins that are native to the operational layer, not an afterthought.
The distinction that matters: This isn’t a “replace everything” argument. Most organizations have a lakehouse or warehouse well-suited for deep history and enterprise analytics. The point is removing the hot-path boundaries - between ingestion and query, between transactional and analytical workloads, between the state your control room sees and the state your models are running from. |
Where distributed SQL fits in
This is where HTAP architectures - systems designed to handle transactional and analytical workloads on the same data in the same engine - become directly relevant to energy operations.
SingleStore is designed specifically for this HTAP principle. Data ingests from Kafka, Event Hubs, and other streaming sources directly into tables that are immediately queryable, without an ETL staging step or a separate serving layer. Transactions and analytics run against the same data with full ACID guarantees. In practice, this means the operational state your control-room operator sees is the same state a forecasting model or AI copilot is working from.
We’ve seen this translate into concrete operational outcomes across energy and adjacent industries:
99% Reduction in data ingestion time for a leading North American media company - from 2+ hours to under 2 seconds | 300x Query latency improvement - from 5 minutes to under 1 second, even at thousands of concurrent users | 15x Reduction in data ingestion latency for a tier-1 cybersecurity provider, with 180x improvement in time-to-insight |
Under heavy mixed concurrency - operators, trading systems, automated workflows, and analytical queries running simultaneously - the runtime stays predictable in a way that systems designed for off-peak BI workloads typically don’t.
The scale of what’s coming
Energy makes this constraint visible first because the consequences are immediate: latency produces instability, inconsistency produces misallocation, and delay produces cost or outage. But the numbers also make clear that the pressure is only going to increase.
Amazon, Microsoft, Google, and Meta collectively spent over $200 billion on data centre capital expenditure in 2024 alone - a 62% year-over-year increase. AI-focused servers are projected to account for 35–50% of all data centre power consumption by 2030, up from roughly 5–15% today. Dominion Energy alone projects its peak demand will rise by more than 75% by 2039 driven by data centre growth.
That load has to land somewhere as the energy transition accelerates. Utilities and grid operators will be managing fundamentally more complex, more volatile, and more data-intensive power systems and grid environments within the decade. The organisations that have already built a data layer capable of real-time coordination will be in a structurally different position from those still reconciling operational state across four systems before they can act.
75%+ Projected peak demand increase for Dominion Energy by 2039, driven by data centre growth - one utility’s window into the grid pressure AI infrastructure will create at scale. |
So what do you actually do with this?
If you’re a CTO, data architect, or operations leader in this space, the argument above probably isn’t surprising. Most people working in energy data already know their architecture is straining. What’s less clear is where to start.
The truth is, most underperforming or stalled AI initiatives in the energy sector aren't failing due to the model itself. They’re failing because the data layer underneath them can’t deliver the freshness, consistency, and concurrency that those models need to do anything useful in production. The model gets the blame. The architecture is the actual problem.
That means the most valuable diagnostic you can run right now isn’t an AI audit - it’s a data movement audit. Pick one operational decision your team makes today that you’d want AI to either support or automate. Then trace every system that data touches between the triggering event and that decision. Count the hops. Measure the lag. Find out whether the state your model sees is the same state your operators see, and whether that’s actually guaranteed anywhere in the architecture.
In most cases, that exercise will show you exactly where the bottleneck is. And it’s almost never where people expect it to be.
The decision in front of you: You’re not choosing between AI vendors or model approaches. You’re choosing whether your data layer will be a constraint on every AI initiative you run for the next five years, or the foundation that makes them actually work. That decision is already being made - by what you invest in, and what you don’t. |
The grid won’t wait for your ETL job to finish. Neither will the organisations building the infrastructure to manage it.
Want to see how SingleStore performs against your own workloads? Get started here.
.png?width=24&disable=upscale&auto=webp)
