Frankfurt Data Centers Are Full: Why New Power Connections Wait Until the Mid-2030s
Mainova says large new power connections for Frankfurt data centers will not return until the mid-2030s. I break the news into three tiers, with the numbers from 18.03.2026 and one deck measurement: a 54-minute video job at 0.5 percent of my Ollama window.

Anyone who wants to build a large data center in Frankfurt gets a queue position from the grid operator, with the earliest big new connections pointing to the mid-2030s. This post answers what that means for people who send their AI workloads through cloud providers instead of running them on their own hardware. The short version: existing plants see no change, new large projects turn the Frankfurt data centers into a question of timing rather than yes or no, and individual agent operators should check their own degradation tiers long before the grid gets tight. I run my agents on a used Pixel 6a, so I read this news as an operator, not an investor.
What was said about Frankfurt data centers
According to the dpa report from mid-March, the utility Mainova says that in particular large, high-capacity new connections can be provided again only from the mid-2030s onward. The reasons given are the construction of new lines, a high need for grid expansion inside the city, demanding permitting processes and a shortage of skilled workers. The administrative boundary is clean: existing data centers can keep operating and can expand within the capacities they already have. Projects whose connection power was registered and promised long ago are not covered either. The restriction hits new large requests, not running operations.
The same source shows the scale of demand: on average 5 to 10 operator requests per year arrive at the grid subsidiary NRM Netzdienste Rhein-Main, 55 data centers already stand in the city area, and 13 more are supposed to join by 2030. The Rhine-Main region owes its attraction to the DE-CIX internet exchange, and that same proximity makes the bottleneck bite. One example from the report: operator Firstcolo wanted to expand at its Frankfurt-Ost site, but the needed power would not have been available before 2035, so the company now builds in a wider radius, with a new AI data center in the Wetterau district scheduled to connect at the end of 2027.
The grid bottleneck moves the site question, it does not cancel demand. Whoever does not build in Frankfurt builds where power is available.
What this news does not say
Three readings are wrong, and each of them shows up regularly in the debate. First, Frankfurt has no blackout and no general supply gap; the bottleneck affects new large connections only. Second, it is not an AI ban: operation and expansion within existing capacities are explicitly possible. Third, the mid-2030s figure is a schedule from the grid operator under present conditions, not a law of nature; it depends on line construction, permits and skilled workers, and those are exactly the factors named as causes.
What you can read from this with confidence is a siting decision with signal character: when connection power for new builds in the most important German data center node is booked out for years, growth shifts into the surrounding region and the rest of the country. The 23 planned regional locations outside Frankfurt are exactly this shift in numbers. For total demand for compute that changes little, for grid planning and for the site decisions of individual operators it changes a lot.
My case: three tiers instead of black and white
The classic mistake with news like this in the agent debate is the binary split: either cloud or fully offline, and offline means your own machine with your own GPU. My setup on a 45-euro phone lives in practice in three tiers, and the distinction is precisely what makes the difference between an outage and throttling when the grid or a provider gets tight. Tier one is full cloud work: model requests, research and verification run through providers. That is the normal state and by far the most common one.
Tier two is throttled cloud: my script universe keeps running, but model calls are cut down to what is necessary, batch jobs are merged, and the order follows a priority list instead of a latency expectation. This is exactly the tier I documented on 05.09.2026: processing a complete 54-minute video consumed 0.5 percent of my Ollama five-hour window, because the mechanical part of the workflow burns no model requests at all. Throttling here therefore does not mean standstill, it means shifting work and concentrating calls.
Tier three is the offline core: automations that get by without the cloud, watchdogs, monitoring, local preprocessing, and a memory that lives on the device. This tier does not replace cloud inference, and the text does not claim it does. It is a conceptual tier model, planned as a response to bottlenecks. I have not yet tested this workflow under real provider throttling. What I have actually documented is the quota side: the video measurement in the paragraph above. Taken together, the three tiers answer the Frankfurt question on a personal level: the location of a data center is not my problem, but my dependence on its capacity is, and that dependence can be managed tier by tier.
Why proximity to the internet exchange matters at all
The Frankfurt bottleneck has this pull because the location does more than consume power: at DE-CIX, one of the largest internet exchanges in the world, routes meet with short paths and small waiting times, and nearby data centers serve that market directly. For classic internet services this proximity is real money, because every millisecond toward customers counts. For this post the decisive point is different: if you consume AI services through an API, you buy compute as a service, not floor space at the exchange. When an operator moves its growth out of Frankfurt into the surrounding region, an API user in the ideal case notices nothing, as long as providers and their connections keep up.
That is exactly why the news is less threatening for agent operators than for operators of trading platforms, and exactly why the tier logic pays off: my dependency does not sit on a Frankfurt plot of land, it sits in the contract with the provider. How reliably that contract grows when capacity is built elsewhere decides response times and prices, not the existence of the service. If you run your own servers at the exchange, on the other hand, you feel the site question directly, because floor space, connection and latency are your product.
Why this matters more for agent operators than it sounds
Many agent setups, as far as I can tell, come without their own backup strategy for the case that cloud offers get tighter; I have no solid numbers on this, it is an observation from my conversations and reading. That sounds more dramatic than it is meant: this is not about the blackout, it is about the unspectacular cases, price increases, quota cuts, queues, regional throttling. The Frankfurt answer is an example of what such limits look like long before anything fails: there is a schedule, there are exceptions, there is a shift into the surrounding region. If you know your own tier logic, you react to news like this with adjustment instead of surprise.
Two concrete precautions have proven themselves here. First, important results land locally, not only in the cloud, because the end of a quota or a provider ban would otherwise take access down with it. Second, my own accounting tracks quota and usage separately, so that throttling becomes measurable instead of showing up only as a feeling in the workflow. What the equivalent of this logic looks like in the power grid, at large scale, is covered by the Texas post, which follows the same debate on the US level.
The honest limits
Four limitations belong in this text. First, my source for the Mainova statement is the dpa report at ZEIT from 18.03.2026; the original Spiegel piece sits behind a paywall and was not directly accessible, and the tagesschau editorial team reported the same matter with the same date. Second, the figures for 55, 13 and 23 sites come from the same coverage and should be read as press statements, not as official statistics. Third, the 0.5 percent measurement is a single measurement from my project operation, documented in the project log, not a test series. Fourth, whether the grid expansion plan holds until the mid-2030s is a forecast by the grid operator, not a guarantee.
Is it true that Frankfurt will not get any new data centers?
Not that broadly. Existing data centers can keep running and expand within the capacities they already have. What is affected above all are new projects with very high power requirements, for which large new connections will according to Mainova be possible again only from the mid-2030s (ZEIT/dpa, 18.03.2026).
Why does grid expansion take so long?
The grid operator names the construction of new lines, a high need for expansion inside the city, demanding permitting processes and a shortage of skilled workers. These factors make grid expansion slow and resource-intensive.
What does this mean for the cloud services I use?
For existing plants nothing changes, your provider keeps running. It becomes relevant with growth: new large sites are increasingly built in the surrounding region and the rest of the country, with 23 additional locations planned outside Frankfurt by 2030. For end users this is first a siting question for operators, not a service outage.
How do I prepare as an agent operator for bottlenecks like this?
By separating three tiers: full cloud work, throttled cloud with reduced model calls, and a local core without cloud dependency. What matters is that the tiers exist before the bottleneck, because you cannot invent them during an outage.
Is the 0.5 percent measurement a general statement about power consumption?
No. It describes the share of one concrete workflow in my Ollama five-hour window, in other words my request quota. Nothing about power consumption or energy savings can be derived from it; the quantities and resolutions do not match.
About the author
About the author: I run the HUNTER cyberdeck as Marcel, a graphic designer and the operator of the d4sn3st sites. Since 2026 I have been running AI agents on a used Google Pixel 6a, and on this blog I document what operating them with limited resources looks like in daily practice. This post is based on the dpa report at ZEIT from 18.03.2026 and the tagesschau coverage, plus my own measurements from 05.09.2026. Last fact-checked on 05.09.2026.