Liquid Cooling and Data Center Water Use

Liquid cooling describes how heat leaves IT equipment. A site's water requirement depends on what happens next: the facility cooling loop, the equipment rejecting heat outdoors, the local climate and the operating conditions.

That distinction belongs in a development brief as early as the power requirement. A proposal can describe a liquid-cooled rack accurately while leaving its annual water balance unresolved. Equally, water circulating inside sealed pipes should not automatically be counted as water consumed on every pass.

For developers, occupiers and investors, the useful starting point is a complete heat path and a defined measurement boundary. The following framework is PowerlandMap's analysis of how to turn public cooling claims into questions that a project team can verify.

Trace the system beyond the rack

The Open Compute Project's Cold Plate work covers the technology cooling system from cold plates to coolant distribution units, including tubing, manifolds and connectors. Its scope illustrates why the rack interface deserves its own specification.

That equipment is one part of the wider facility. The project team should identify how heat crosses into the building's cooling system and how it ultimately reaches the outdoor environment. Asking only whether the servers use liquid leaves that final stage unspecified.

A useful evidence pack therefore contains a heat-flow diagram, equipment schedules and a description of operating modes. PowerlandMap's earlier analysis of cooling interfaces addresses the connection between systems. Water diligence extends that review to the site's resource balance.

Read operator claims at their stated boundary

In its December 2024 design announcement, Microsoft described recirculating water between servers and chillers without evaporative cooling. It explicitly retained water use for administrative purposes. It also acknowledged an energy trade-off when replacing evaporative systems with mechanical cooling.

The precise claim concerns a cooling design. It does not establish that every Microsoft facility, every operating mode or the entire supply chain has no water requirement.

In June 2026, Microsoft distinguished several cooling methods, including cooling towers, hybrid fluid coolers and air-cooled chillers. That distinction matters when evaluating a proposed site: a headline about liquid cooling does not identify which heat-rejection method has been selected for that project.

Similarly, AWS's explanation of its liquid-cooling rollout describes coolant recirculating through cold plates and a heat-rejection system. AWS says this implementation does not increase data-center water consumption. That is an operator-specific design statement, not a universal performance figure for every liquid-cooled installation.

The diligence task is to attach each claim to a named design, location, load and date. This follows the same evidence discipline used in capacity classification.

Keep four water questions separate

First, what volume is needed to fill the system and carry out commissioning? Record this separately from recurring operation.

Second, what water enters the site during normal operation, from which source, and for which uses? The evidence should distinguish cooling, humidification and other facility requirements.

Third, how much is returned, discharged or consumed? The IEA's Energy and AI report, Box 5.4 distinguishes withdrawals from consumption and examines both direct and indirect water use. A withdrawal figure and a consumption figure should not be presented as interchangeable.

Fourth, what falls outside the site meter? Electricity supply and semiconductor manufacturing introduce additional water impacts. Those require a wider assessment boundary and should be reported separately from the facility's operational water balance.

For a powered-land assessment, this becomes a practical document request: the source agreement, connection requirements, forecast demand profile and assumptions behind each number.

Compare designs under the same conditions

A comparison is meaningful only when the proposed IT load, climate data, temperature requirements and availability assumptions align. Otherwise, a lower water figure may describe a different duty rather than a better solution.

Ask the engineering team to provide an annual operating estimate and a separate peak-day requirement. Include the anticipated ramp-up profile, maintenance conditions and any mode that uses water during hot weather. Identify which results come from simulation and which come from operating measurements.

Microsoft's published design discussion is useful precisely because it acknowledges the interaction between cooling energy and water. The commercial implication is to evaluate the resource trade-off explicitly, instead of optimizing one headline metric in isolation.

The effect on power demand belongs alongside grid-connection diligence. A cooling assumption that changes electrical demand can affect the project's capacity balance and delivery plan.

Treat the water arrangement as a delivery milestone

PowerlandMap's recommended review separates three evidence stages: a modeled requirement, a documented supply arrangement and an operating result.

At the first stage, record the design basis and unresolved assumptions. At the second, obtain evidence covering the required source, volume, timing and service conditions. At the third, compare measured performance with the original design case.

A project team's review should also ask:

• Who owns the water-demand calculation and approves revisions?
• Does the supply arrangement cover the intended phases?
• Which operating conditions produce the highest demand?
• What changes during maintenance or loss of a cooling component?
• Are discharge and treatment assumptions documented?
• What evidence remains outstanding before the next project commitment?

These are questions to resolve with the relevant engineers and utilities, rather than claims that every jurisdiction requires the same documents. They complement permit diligence and a project-specific development milestone plan.

Make the public explanation match the engineering

Communities need a description they can reconcile with actual infrastructure. State what the system circulates, what the site withdraws, what it consumes and which uses a claim excludes. Give the period, source and status of the estimate.

For a brownfield conversion, distinguish the existing arrangement from the proposed modification. A feature in the future design should not be presented as an operating result today.

At commissioning, define which measurements and acceptance evidence will substantiate the design claim. That creates a path from an early estimate to a result the operator can explain and track.

A better starting point for site selection

A cooling label cannot answer the complete water question. A documented system boundary can organize the evidence needed to answer it.

The strongest project narrative connects the IT configuration, cooling architecture, local conditions, utility arrangements and verification plan. It shows what is known, what is modeled and what still requires confirmation.

For teams comparing locations, request access to PowerlandMap to put infrastructure signals and their evidence in the context of the wider site-selection decision.

*Analysis published on 12 October 2026. Operator descriptions are attributed to their original publications and should be checked against the specific project design. Hero image: conceptual illustration.*