Modular Data Center Design Principles and Engineering Tradeoffs

Modular data center design gets marketed as a single purchasing decision: pick a vendor, order a module, get a building faster than you would with a general contractor. That is not how it works in practice. Modular design is a chain of engineering commitments, and each one locks down what the next can be. Power density has to be settled before cooling architecture makes sense. Cooling has to be settled before factory scope can be defined. Factory scope has to be settled before anyone can honestly talk about cost or schedule. Get the order wrong, and a decision made in month two quietly breaks a decision that needs to happen in month eight.

Teams that skip this sequencing tend to find out the hard way. A cooling vendor gets chosen before the power architecture is final. A factory start date gets accepted before redundancy topology is resolved. Then, mid-project, someone discovers the module can't actually support the rack density the facility was supposed to host, and there's no clean way back. The fix at that point costs months, sometimes a full redesign cycle. None of this is a failure of execution. It's a dependency chain, and understanding which decision gates which is the real engineering discipline here, long before an RFQ goes out.

Power density as the first constraint that makes every other decision harder

Power density has to be the first number settled in any modular AI data center project, because every other decision, cooling type, redundancy design, even factory layout, depends on what that number is. Try to pick a cooling architecture or a module footprint before rack density targets are locked, and the project will end up revisiting that choice later, usually at a worse time and a higher cost.

The scale of the problem is specific. GPU-centric AI racks routinely exceed 100 kW per rack now, and some reach or pass 300 kW per rack. A facility designed even five years ago, before this generation of hardware, simply wasn't built to carry that kind of load. Floor loading limits, power distribution capacity, and thermal rejection systems all hit physical ceilings well before a retrofit could close the gap. That's why older buildings can't just be upgraded into AI hosting sites. The structure itself is wrong for the load.

This density problem forces two decisions that teams often treat as afterthoughts, but which actually need to happen early:

Redundancy topology, whether a facility runs N, N+1, or 2N, is a workload decision. An inference fleet serving live customer traffic has a very different availability requirement than a training cluster, where a dropped job costs compute time and money but doesn't take down a product for end users. Choosing redundancy topology means first knowing what the GPUs are actually doing, not applying a standard enterprise assumption to an AI workload.

UPS sizing, harmonic filtering, and power distribution all need to be built around load swings, not averages. AI training runs spike GPU draw sharply, then drop just as sharply when a run finishes. These step loads don't look like the steady, predictable draw that standard enterprise UPS systems were designed around. Size the power system for an average load, and the facility will struggle the first time a training job spikes.

Both of these, redundancy topology and power sizing, have to be resolved at the workload level before factory scope gets defined. A module built around the wrong redundancy topology or undersized UPS capacity cannot be fixed once fabrication starts. That's a design that has to be caught before it's built, not after.

Power has also become the actual constraint on where a facility can be sited. Site selection used to start with land and fiber access. Now it starts with substation capacity and a project's position in the grid interconnection queue. US projects that reached commercial operation in 2024 spent an average of 55 months in the interconnection queue, a figure reported in Lawrence Berkeley National Laboratory's Queued Up report (2025). That number alone should reframe how early in a project's life power planning needs to begin. The facility is, in a very real sense, an industrial power-and-cooling plant that happens to also house compute. Treated like a standard building with servers in it, the facility's power constraint surfaces late in the project and becomes expensive to fix.

Cooling architecture must follow power density, not run in parallel with it

Cooling is a direct consequence of whatever power density gets settled first. Lock in a cooling strategy before rack density is confirmed, and one of two bad outcomes follows: the facility over-provisions thermal capacity and strands cost on equipment it doesn't need, or it under-provisions and ends up with a building that can't actually run at its rated load.

There's a clear line in the hardware generations here. The last generation broadly compatible with air cooling was the H100. Everything that has come after it is a hard engineering requirement. That requirement pulls a whole chain of infrastructure into the base building: coolant distribution units, facility water loops, leak detection systems, manifold-ready racks. None of these are add-ons. They're structural.

Retrofitting liquid cooling infrastructure into a hall that was built for air cooling is slow and expensive, often involving downtime in a facility that's already operating. Designing it in from day one costs far less and moves far faster. That's the whole argument for why the cooling commitment has to come before factory design starts, not after.

The real, durable advantage of modular construction in the AI era is density management. A purpose-built modular system designed for high-density liquid cooling can be configured for these loads from the start, because the module gets designed around the thermal and power requirements of the rack rather than the rack getting squeezed into whatever the module already assumed. Traditional construction can reach the same result, but doing it through a fully custom design process can take just as long as modular procurement does, which erases the speed advantage usually cited as modular's selling point. The advantage that survives scrutiny is alignment between the module and the load it's built to carry, not raw delivery time.

Liquid cooling also changes what happens to the heat a facility produces. It delivers higher-grade, reusable heat, and that distinction is becoming more than a technical footnote. The European Commission published a data-center rating-scheme package on September 21, 2026, and is consulting on possible minimum performance standards for data centers. That consultation is active and points toward a regulatory environment where what a facility does with its waste heat matters to compliance, not just to operating cost. Waste heat recovery becomes a revenue conversation instead of a disposal problem when the thermal output is high enough grade to use elsewhere. Whether that option even exists for a given facility gets decided by a cooling architecture choice made early in the design process, long before anyone is thinking about heat-reuse mandates.

What "factory-versus-site" means when the decision has to be made

Once power density and cooling architecture are settled, the next question is how much of the build happens in a factory and how much happens on site. This is a question of where each category of interface, electrical, thermal, structural, gets resolved, and teams that treat it as all-or-nothing tend to make one of two mistakes. They over-modularize and end up shipping integration problems to the site anyway, or they under-modularize and lose the schedule compression that was the whole reason to go modular.

The range of what "modular" actually covers is wider than most buyers assume. The modular project forms worth distinguishing are a complete modular facility, an IT or data-hall module, a power or cooling module, a compact edge facility, and a hybrid campus that combines repeatable factory-built blocks with site-built infrastructure. Each of these leaves a different set of interfaces unresolved at the time of delivery, and each answers a different buyer's actual requirement. An electrical skid and a complete IT facility can get counted in the same market revenue estimate, even though they solve completely different problems. The useful comparison for a buyer is the exact scope being delivered, module by module.

Large AI projects increasingly blend prefabricated electrical, thermal, and IT packages with conventional civil construction on site. A container is one possible enclosure for a module, not a definition of what the modular sector is. Thinking of modular as "the shipping container approach" misses most of what's actually being built today.

The real schedule case for going modular doesn't come from factory workers assembling parts faster than site crews could. It comes from factory manufacturing and site construction happening at the same time, as overlapping workstreams. That's a meaningful distinction, because it changes what a buyer should actually expect from going modular. The gain is in parallel timelines, not in faster individual task execution.

None of this comes free. Transport constraints cap how large a single module can be. Customization has to get locked down before production starts, because changes mid-fabrication are far more disruptive than changes on a site-built project. Regulatory frameworks and authority-having-jurisdiction requirements vary by location and require factory-based verification protocols that look different from the inspection process on a traditional build. These are real constraints that a buyer needs to plan for in advance, before they surface partway through a project.

Traditional construction still holds real advantages at the largest scale. At gigawatt-scale campus developments, the procurement volume lets major operators negotiate directly with equipment manufacturers at efficiencies no modular supplier can match on a per-module basis. The flexibility to optimize cooling strategy, power architecture, and heat reuse around the specifics of a given site can be worth the added complexity when that design gets replicated across millions of square meters. The factory-versus-site decision, in other words, depends on scale and repeatability as much as it depends on speed.

The narrower CAPEX case for modular

Modular construction does not automatically cost less than a traditional build. Teams that build their business case around an assumed discount per megawatt, rather than around schedule, predictability, and phasing, tend to end up disappointed when the invoices arrive. The economic case for modular runs through different mechanisms than a straightforward price cut.

Prefabricated modules can be faster to deploy and more predictable in cost, and they can be delivered at a cost similar to traditional stick-built data centers. That's a meaningfully different claim than "cheaper." The value is in the predictability and the schedule, not in a universal construction discount.

The cost environment in 2026 strengthens the case for schedule certainty. Average global shell-and-core data center construction costs are forecast to rise in 2026 compared with 2025, driven by rising demand, extended lead times, and limited availability of skilled trades. Data center contractors are also carrying substantially more backlog than contractors without data center exposure, based on JLL's U.S. construction update. In a labor market that tight, avoiding months of site congestion has real economic value, even when the manufactured equipment itself costs roughly the same as a site-built equivalent.

The cleaner economic argument for modular is stranded capacity. Modular infrastructure tends to reduce the cost of capacity that sits unused, because teams build to what they need now instead of building for a load level they expect to reach years later. Traditional facilities often carry years of underused capacity, paying to cool and power racks that stay empty while the facility waits to grow into its design. That's a real cost, and modular's phased approach avoids much of it.

But that advantage only shows up if phased scalability gets engineered into the module design from the start. A module that can't be extended without redesigning the shared electrical or cooling infrastructure underneath it doesn't actually deliver phased capacity, no matter what the sales materials promised. That constraint is the subject the next section takes up directly.

Phased scalability as an engineering commitment, not a procurement option

Phased scalability means adding capacity in increments without redesigning what's already built. That only works if the electrical, thermal, and controls interfaces between modules get standardized at the design stage, before the first module is ever fabricated. Teams that treat scalability as an option to exercise later, once growth actually happens, tend to find that the first module's architecture already decided the answer for them, usually in the wrong direction.

The hybrid campus model, repeatable factory-built blocks paired with site-built infrastructure, is the dominant form for large AI deployments today. It's also the model that concentrates interface complexity at exactly the boundary that a phased expansion has to cross. Every point where one module connects to the next, electrically, thermally, through controls, is a point where a standardization decision made early either enables or blocks future growth.

The timeline for grid power has made this more urgent, not less. Grid interconnection timelines in many markets now run several years before a single shovel hits the ground. Operators can no longer plan to add capacity incrementally in the old sense, requesting more power as demand grows, because the lead time for new power access can span years on its own. That forces a different kind of planning: utility power, liquid-cooling loop design, and GPU hardware roadmaps all have to get treated as one interdependent system from the moment a site gets selected, not as separate tracks that get coordinated later.

Phased scalability, in the end, is a property that either exists in the first module's design or doesn't exist at all, and by the time a second phase is needed, it's too late to go back and build it in.