The interconnection queue decides which datacentres get built, on rules written for power plants

Ask a datacentre developer what their hardest problem is and the answer will not be construction, capital or tenants. It will be a queue. Connecting a large load to the transmission system requires a sequence of engineering studies run by a regional operator, and the sequence takes between three and four and a half years in the markets where most of the current building is happening. Nothing in the development timeline can move faster than that sequence, which means the queue, rather than the building, is the actual product.

The rules governing this were written in the late 1990s for a different problem. Deregulation had created independent power producers who wanted to build generation and sell into a market, and the transmission owners they needed to connect to were often their competitors. The interconnection process exists to stop a transmission owner from favouring its own plants, which it does by imposing a rigid, first come first served, study based sequence that treats every request identically. It worked. It was also built around a world in which requests arrived at a rate of dozens a year rather than thousands.

The four studies

Every request moves through the same stages, and each stage answers a narrower question than the one before it. The important structural feature is that stages two and three are run in clusters, which means a request is studied alongside every other request that entered in the same window rather than on its own.

The second stage is where schedules are made and lost. A system impact study models the transmission network with every request in the cluster assumed to be built, then identifies the upgrades required to keep the network within its limits. Because the answer for any one request depends on the assumptions made about all the others, a withdrawal by a large applicant upstream changes the result for everyone behind it. The operator then has to restudy, and restudy is where a year disappears.

Speculative requests make the restudy problem far worse. Filing an interconnection request is cheap relative to the option it creates, so developers have historically filed on many more sites than they intended to build, keeping every position alive until financing or a tenant arrived. Queues in some regions have carried three to five times more requested capacity than any plausible construction programme, and every one of those phantom requests sits inside the study assumptions for the real ones.

Why load is harder than generation

A generator and a large load both connect to the same wires and they stress the system in opposite directions, which the process was not designed to distinguish. A generator adds energy at a point and the study asks whether the network can carry it away. A load removes energy and the study asks whether the network can deliver it, at the worst hour of the worst day, with the largest single element out of service. That second test is harder to pass in a zone that was already importing power.

• A large load cannot be curtailed the way a generator can, at least not under standard terms, so the study cannot assume it away during system peaks.
• Datacentre load has an unusually flat profile, which is helpful for utilisation and unhelpful for a planning process built on the assumption that peak demand happens for a few hours on a few days.
• Load growth requires firm capacity rather than energy, and firm capacity in a constrained zone means either new generation inside the zone or new transmission into it, both of which take longer than the queue itself.
• Behind the meter generation changes the answer completely and is treated inconsistently across regions, which is why several developers now propose their own on-site generation as part of the original request.

The first question in every site acquisition is not what the land costs. It is what date is on the study and whether the cluster behind it has any large withdrawals pending. We have walked away from cheaper sites with better power prices because the queue position was two years behind, and two years is the whole deal.

Tomas Weir, chief commercial officer at Meridian Grid Compute

The reforms being attempted

Every regional operator is now running some version of queue reform, and the approaches divide into three families. The first tries to stop speculative filings by making them expensive. The second tries to reduce restudy by processing requests in fixed, closed clusters rather than continuously. The third tries to sidestep the process entirely by letting a customer connect to existing capacity under conditions that limit its use.

The fourth row is where the real answer probably lies. A load willing to reduce consumption for a few dozen hours a year during system peaks does not require the same firm capacity as one that insists on full power at all times, and the studies get dramatically easier. Training workloads can tolerate interruption in a way that inference serving a live product cannot, which means the flexibility is technically available for a meaningful share of the demand. Whether tenants will sign for it is a commercial question that two or three operators are currently testing.

Anyone underwriting datacentre development should read the queue file rather than the pitch deck. The date on the system impact study, the composition of the cluster, the identity of the large requests ahead in the same zone and the lead time quoted for the specific transformers in the facilities study will tell you more about when a building energises than any construction schedule. The concrete has never been the constraint. The paperwork is, and it has been for four years.