...
NVIDIA H200 shipments delayed to Q3  · BREAKING: Microsoft confirms 3GW data centre expansion in Asia-Pacific ·  AWS announces new sovereign cloud regions in India and UAE  · Arm-based servers now 24% of hyperscale deployments ·  EU AI Act enforcement enters phase two  · Global data centre investment hits $612B in 2026 ·  TSMC Arizona yields improve to 68% on 3nm process  · OpenAI valuation reaches $400B after latest funding round ·  NVIDIA H200 shipments delayed to Q3  · BREAKING: Microsoft confirms 3GW data centre expansion in Asia-Pacific ·  AWS announces new sovereign cloud regions in India and UAE  · Arm-based servers now 24% of hyperscale deployments ·  EU AI Act enforcement enters phase two  · Global data centre investment hits $612B in 2026
NVIDIA H200 shipments delayed to Q3  · BREAKING: Microsoft confirms 3GW data centre expansion in Asia-Pacific ·  AWS announces new sovereign cloud regions in India and UAE  · Arm-based servers now 24% of hyperscale deployments ·  EU AI Act enforcement enters phase two  · Global data centre investment hits $612B in 2026 ·  TSMC Arizona yields improve to 68% on 3nm process  · OpenAI valuation reaches $400B after latest funding round ·  NVIDIA H200 shipments delayed to Q3  · BREAKING: Microsoft confirms 3GW data centre expansion in Asia-Pacific ·  AWS announces new sovereign cloud regions in India and UAE  · Arm-based servers now 24% of hyperscale deployments ·  EU AI Act enforcement enters phase two  · Global data centre investment hits $612B in 2026

The Million-Gallon Benchmark Is Not Enough. What Metric Should Replace It?

A large round number has a peculiar ability to become infrastructure folklore. Once a water-use estimate enters public discussion, it

Share
Full-Stack Water Score

A large round number has a peculiar ability to become infrastructure folklore. Once a water-use estimate enters public discussion, it can be repeated across reporting, policy discussions and commentary even when the underlying methodology and operating conditions are not carried forward with the figure, a problem reinforced by the lack of standardized and complete water-use reporting across the sector. The credibility of a water-use figure depends on the transparency of its measurement basis, because current evidence shows that reported data-center water estimates can represent different boundaries, assumptions and operating conditions rather than a single standardized measurement. The underlying technical literature has already warned that direct data center water use provides only a partial view of the broader water footprint associated with computing.

The authority of a number that nobody owns

The problem becomes sharper when a rounded estimate starts functioning as a proxy for an entire class of infrastructure. A reader sees a memorable quantity and can easily interpret it as a normal operating requirement rather than as an upper-end illustration, planning assumption or context-specific estimate. The distinction can disappear when a reported figure is separated from the assumptions, facility characteristics and measurement boundary that originally gave the figure meaning, particularly when data-center water use is reported through estimates rather than standardized site-level measurements. Infrastructure reporting therefore benefits from identifying what was measured, where and when it was measured, and which part of the water system the measurement represents, because those details determine whether a figure describes direct site consumption, an estimated requirement or a broader modeled footprint.

A defensible benchmark therefore needs provenance before it needs precision. The first question should be whether a reported figure has a defined measurement boundary and identifiable evidence behind it, rather than whether its scale appears sufficiently large to represent the water requirements of an entire category of computing infrastructure. Water-use effectiveness already establishes this principle by defining a specific relationship between site water consumption and IT energy use rather than treating a generic consumption figure as universal. That approach creates a traceable denominator and makes comparisons more meaningful, although it still leaves the electricity supply chain outside the site boundary. A replacement metric should preserve that traceability while extending the accounting boundary to the water consequences of producing the electricity that enables the workload.

Why repetition cannot substitute for measurement lineage

The persistence of a benchmark often reflects how easily infrastructure stories compress complicated systems into a single image. Cooling towers, water treatment, electricity generation, weather conditions and workload behavior become one headline number because the number is easier to communicate than the system behind it. That simplification can be useful for public communication when the underlying assumptions remain visible. It becomes misleading when the simplified figure survives after its original context has disappeared. The technical literature distinguishes between water used directly at a computing site and water associated with electricity generation, showing why a single site-level number cannot automatically describe the full water footprint of computing. Measurement lineage also matters because water does not behave like a generic commodity once geography enters the calculation. A liter consumed from a stressed basin does not carry the same local consequence as a liter consumed where water availability and replenishment conditions differ.

Cooling is 8%. The Other 92% Lives Somewhere Else

A cooling system makes one part of water demand visible because its consumption occurs at the physical computing site, while another part of the broader footprint can arise through the electricity system that supplies the computing operation. Water enters a cooling process, moves through equipment, leaves through evaporation or discharge pathways, and can therefore be monitored through meters and operational records. Electricity creates a less visible relationship because the water associated with generating power occurs away from the computing site. That separation allows a site report to describe its observed water use accurately while still leaving part of the workload’s water footprint outside the reported boundary. The distinction between site water and source water has been documented in technical research for years, which means the conceptual gap is not new even though the procurement implications remain underdeveloped.

Observed water is only the water the site can see

The important shift is therefore from observed water to embedded water. Observed water describes what the operator can meter directly around the computing environment, while embedded water describes water consumption associated with the energy system that makes the computing activity possible. Neither category should replace the other because they answer different questions. Site water shows how effectively the physical computing environment manages heat and related processes, while source water reveals how the electricity supply changes the broader resource footprint of that same computing activity. A full accounting must retain both signals rather than collapsing them into a single operational measurement before the upstream relationship has been established.

That distinction also changes the meaning of a seemingly efficient cooling system. A low direct water requirement can reflect an effective thermal design, but it does not by itself establish a low total water footprint because the electricity required by that design can carry an additional water burden upstream. Conversely, a site that uses more water directly may still operate within a broader electricity system whose upstream water intensity differs substantially from another location. The comparison therefore needs two separate questions: how much water does the computing site consume, and how much water is associated with producing the electricity it uses? The Full-Stack Water Score proposed here begins by keeping those questions separate before combining them into a procurement-facing signal.

The hidden boundary is the electricity connection

Electricity becomes the missing boundary because computing demand does not stop at the meter that records power entering the site. Electricity generation can require water depending on the generation technology, cooling arrangement, fuel pathway and operating conditions of the wider power system. The resulting water relationship can remain invisible in conventional data center sustainability reporting because operational water disclosures usually focus on water directly associated with the site. Research into data center water consumption has specifically identified electricity generation as an important component of the broader footprint. A source-water layer would make that relationship explicit without pretending that every unit of electricity carries the same water consequence. The calculation would begin with the electricity actually attributable to the workload or computing operation and then apply a defensible water-intensity factor for its source.

The factor would need a documented geography, generation boundary, temporal basis and data provenance so that procurement teams could distinguish measured information from modeled assumptions. That requirement is important because existing research has also identified the availability of reliable water-intensity factors as a practical limitation when calculating source WUE. The proposed shift is consequently not an argument that cooling water has become irrelevant. It is an argument that cooling water should no longer stand alone as the definition of computing water impact. Together they create the beginning of a water-accounting chain that can later incorporate the temporal and basin-specific conditions required to distinguish where and when the same computational work creates different resource pressures.

What Operators Actually Disclose And What They Quietly Skip

A sustainability disclosure can be technically accurate while still leaving an important part of the water story outside its boundary. Operators commonly report water withdrawal, water consumption, discharge and WUE because those measures connect directly to the physical operation of the computing site. Such disclosures can also distinguish between municipal water, groundwater, reclaimed sources and areas exposed to higher baseline water stress, giving readers useful information about where direct water demand occurs. Equinix, for example, publicly separates withdrawal, consumption, discharge and WUE in its sustainability data, while also distinguishing portfolio-wide WUE from WUE at sites using evaporative cooling. A procurement process that treats the published WUE figure as the entire water footprint therefore risks comparing only the portion of the system that happens to sit behind the site’s water meter.

The water meter sees the site, not the system

The reporting boundary becomes even more important when cooling water and electricity-related water consumption move in opposite directions. A site can reduce direct water consumption through a cooling configuration whose electricity requirements differ from those of another cooling approach, creating a potential trade-off between onsite water use and upstream water consumption that depends on the specific technologies and electricity system involved. Another site can operate with a higher direct water requirement while drawing electricity from a generation mix with a different water profile. Neither outcome automatically represents superior or inferior environmental performance because the trade-off depends on the relationship between cooling, electricity generation and local water conditions. Recent research continues to treat direct and electricity-related water consumption as separate components of a data center’s operational water footprint, reinforcing the need to keep those components visible before combining them.

The reporting gap is therefore not necessarily a failure to disclose water information, because operators can provide direct water measurements while the electricity-related water consumption remains outside the site’s reporting boundary. A site can tell a buyer exactly how much water its cooling systems consume and still leave the buyer unable to determine the water consequences of the electricity supply. That gap becomes consequential when procurement compares locations with different generation systems or different hydrological conditions. Source WUE addresses part of this problem by extending the accounting boundary beyond onsite consumption to estimated water consumed in the energy supply chain. A more complete procurement framework should retain that source layer while adding the location and timing needed to interpret whether the resulting water burden falls in a resource-constrained basin.

Comparable WUE does not mean comparable water impact

WUE becomes powerful when its boundary remains explicit. The measure relates water used for cooling and humidification to IT energy, which allows operators to track changes in the water performance of the computing environment without reducing the analysis to an absolute volume. Microsoft describes WUE in this way and explains that location and climate conditions can influence the result, which is why the metric works best as an operational efficiency measure rather than as a universal statement about environmental impact. The same principle applies when comparing two sites because the WUE number needs its cooling configuration, climate context and reporting boundary to remain attached to it. Once those conditions disappear, a comparable-looking value can acquire a meaning that the underlying measurement never intended to provide.

The next step is not to abandon corporate sustainability reporting but to make the disclosed information interoperable. A useful disclosure should identify the water boundary, electricity attribution method, source of the water-intensity factor, geographic basis and period represented by the calculation. The same disclosure should distinguish measured site consumption from modeled upstream consumption because the two values carry different levels of direct verification. This distinction becomes particularly important when buyers compare an existing site with a proposed site, since modeled source-water values may rely on regional electricity assumptions rather than facility-specific generation attribution. A transparent procurement request can handle that uncertainty by asking suppliers to identify the data source and methodology instead of demanding false precision. The result is a water disclosure that remains useful even when the underlying electricity system changes, because the buyer can update the source layer without rewriting the entire site-water record.

From Site WUE To Source WUE: Where The Measurement Should Really Start

Site WUE begins at the physical boundary of the computing operation. Source WUE extends the accounting boundary by incorporating water consumption associated with the electricity used by the computing operation, building on an approach already described in the research literature rather than introducing a new standalone measurement concept. The distinction creates a second accounting layer rather than replacing the first, which keeps cooling performance visible while exposing the upstream water relationship. Research on data center water consumption has already established the conceptual basis for this approach by separating onsite water consumption from water consumption associated with electricity generation. The proposed procurement model uses that separation as a foundation and treats source WUE as an attribution problem rather than as a new cooling-efficiency measure. That framing matters because electricity is not inherently water-intensive or water-light in every circumstance, and the relevant answer depends on how and where the electricity gets produced.

Source WUE follows the electricity into the calculation

The source calculation should therefore start with the electricity attributable to the computing workload or operating boundary. The next layer should identify the relevant generation mix or electricity source and apply a documented water-consumption factor that corresponds to that source and geography. Where the electricity comes through a shared grid, the methodology should state whether it uses average generation characteristics, marginal generation characteristics, contractual supply characteristics or another defensible attribution method. Different approaches answer different questions, so procurement teams should not treat them as interchangeable. Research into electricity-related water footprints has demonstrated the importance of regional electricity attribution and has proposed methods for connecting electricity consumption with water scarcity impacts. The calculation should therefore expose the attribution method rather than presenting the resulting figure as though it were a direct meter reading.

Source WUE also needs a clear distinction between water withdrawal and water consumption. Withdrawal describes water taken from a source, while consumption generally captures the portion that does not return to the same water system in the relevant timeframe or manner. The distinction matters because electricity-generation technologies can interact with water resources differently depending on their cooling and operating arrangements. A source-water metric that mixes withdrawal and consumption would make comparisons difficult and could exaggerate or obscure the actual resource burden. The procurement specification should therefore require the same water-accounting definition across every supplier response and preserve the underlying source data for audit and recalculation. That approach turns Source WUE from a headline sustainability claim into a reproducible technical input that can feed a broader water-impact score.

The second layer needs provenance before precision

A Source WUE value should never arrive as an unexplained number. Its credibility depends on knowing which electricity data produced it, which water-intensity factor supported the calculation and which geographical boundary connects the two. The methodology should also identify whether the factor reflects generation alone or includes additional parts of the electricity supply chain, because different boundaries can produce materially different interpretations. Published research has highlighted the difficulty of obtaining sufficiently reliable water-intensity factors, making transparency around assumptions as important as the final calculation itself. A procurement framework can manage this problem by requiring a confidence classification alongside the source-water value without pretending that every estimate has the same evidentiary strength. That gives buyers a way to distinguish directly measured information, documented regional factors and modeled estimates while keeping all three categories usable.

The methodology should also avoid treating renewable electricity procurement as an automatic zero-water condition. Electricity generated without direct combustion can still have water implications across its infrastructure and supply chain, while contractual instruments can represent a purchasing arrangement rather than a physical delivery path. The relevant question for Source WUE is therefore not simply whether an electricity contract carries a renewable attribute. It is whether the methodology can explain the water characteristics assigned to the electricity used by the workload and why those characteristics are appropriate. A technically defensible score can accommodate different procurement structures if the attribution rules remain explicit and consistently applied. This preserves comparability without turning the metric into a judgment about one electricity technology or commercial arrangement.

A Single Water Metric Procurement Teams Can Actually Ask For

A useful procurement metric should connect the water consumed directly by the computing operation with the water associated with producing the electricity that enables that operation. The first component captures water consumed through cooling and related site processes, while the second captures water consumption associated with electricity generation and delivery. Temporal and basin weighting can then adjust the electricity-related component so that the same computing demand does not receive an identical water interpretation regardless of when or where it operates. The conceptual structure can therefore combine direct operational water use with electricity-related water consumption and then apply geographic and temporal context to the latter component. The underlying values should remain visible beside any composite result so the final number never becomes a black box.

Connecting the missing layers

The procurement value comes from turning that structure into a question suppliers can answer consistently. Instead of requesting a broad statement about being water efficient, an RFP can ask for measured water consumption associated with the computing operation, the electricity-related water intensity assigned to the workload, the geographic basis of that calculation and the temporal basis used for the electricity factor. The request can also ask suppliers to identify which inputs come from direct measurement and which rely on modeled or published factors. That language keeps the requirement technical without forcing procurement teams into specialized audit terminology or requiring suppliers to redesign their existing sustainability reporting. Buyers can then compare the underlying components before using the combined result as a secondary selection signal.

A practical RFP should also require the methodology to remain consistent across competing bids. If one supplier reports direct consumption while another reports an estimate derived from a generic operational assumption, the two results should not enter the same ranking without a visible distinction. The buyer should ask for the measurement period, reporting boundary, electricity attribution approach, water-consumption definition and source of every external factor used in the calculation. The procurement document should also require suppliers to disclose material changes in cooling configuration or electricity sourcing that could alter the reported result during the contracted period. This creates a measurement obligation without prescribing a particular cooling technology, electricity technology or operational architecture. The resulting procurement process can remain open to different technical approaches while requiring every supplier to expose the same underlying water-accounting layers.

The number should compare decisions, not manufacture certainty

A composite metric becomes useful only when the people using it understand what it can and cannot tell them. The proposed metric should instead place direct operational water consumption and electricity-related water consumption within the same procurement structure while retaining their individual values for transparency. Its role is to reveal differences that direct operational water reporting alone cannot show, particularly where electricity sourcing and local water conditions materially change the upstream burden. The metric can help buyers compare alternative operating locations, electricity arrangements or workload schedules while preserving the underlying measurements needed to understand why one option performs differently from another. The same structure can also accommodate improving data quality because a supplier can replace a regional estimate with a more specific source factor without changing the basic architecture of the calculation. This makes the framework more durable than a fixed benchmark built around one memorable consumption estimate.

The metric should also resist the temptation to convert every environmental consideration into one number. Water availability, electricity emissions, reliability and cost answer different procurement questions and should remain separately visible even when water becomes a formal selection criterion. A water-impact metric can sit alongside those measures because its purpose is to improve water accounting rather than create a universal environmental ranking. The component values should remain available to technical reviewers so that a lower result can be traced to better cooling performance, a different electricity source, a more favorable temporal profile or a different basin context. That traceability gives the number analytical value because the buyer can identify which underlying condition created the difference. A metric that cannot explain its own result would reproduce the weakness of the benchmark it is intended to replace.

What Thames Water’s Public Records Tell Us About Mains Versus Myth

The most revealing evidence about large computing sites does not always come from an operator’s sustainability report or a widely circulated estimate, because utility and planning records can expose the difference between projected water requirements and the information actually available about operational consumption. A parliamentary evidence submission illustrates this distinction by stating that Thames Water estimated it served around 100 operational data centers but did not have exact numbers and did not hold records showing how much water those data centers actually used. That gap is important because it separates a theoretical statement about what a large facility might consume from an observed picture of what the wider customer base actually draws from the network. The lesson is not that large computing sites have insignificant water requirements, but that credible water accounting must distinguish between estimated maximum demand, planned demand, permitted abstraction and measured consumption.

When a national claim meets a local water record

The utility’s own planning material makes that distinction especially visible because it discusses computing demand as one element within a much larger water-supply system. That framing changes the question from whether a single dramatic estimate is technically possible to whether the local network can identify, plan for and manage the actual demand associated with individual connections. A water network does not experience a headline figure as an abstract environmental concept because it experiences customer connections, peak demand, treatment requirements, storage constraints and changes in consumption patterns. The difference matters for computing infrastructure because water demand can become most consequential when cooling requirements coincide with periods when the wider network is already under pressure. A procurement metric that ignores this operational context can therefore produce a technically neat result while missing the condition that determines whether the demand creates meaningful local pressure.

Local context turns an alarming number into an accountable measurement

The utility record also demonstrates why water accounting needs a local context before a national comparison can become meaningful. Public planning documents describe computing developments alongside population growth, climate pressures, existing water demand and the need to maintain resilience across the wider supply area. That context changes the interpretation of the same consumption figure because the significance of additional demand depends partly on the condition of the water system serving it. A workload that produces a particular water requirement in one location cannot automatically receive the same resource-impact interpretation when supplied through a different basin, network or hydrological regime. This approach avoids both extremes, because it neither dismisses computing water use nor assumes that every large estimate represents the same environmental consequence.

This case ultimately exposes the weakness of the old benchmark without requiring the benchmark to be dismissed as entirely meaningless. A dramatic water estimate can draw attention to a genuine resource issue, yet its usefulness declines when readers cannot trace whether it came from measurement, planning, modeling or repetition. Public records surrounding regional computing demand show that even the organizations responsible for supplying water may lack complete site-level consumption information, which makes precision claims particularly difficult to defend without supporting data. The stronger approach is therefore to build water procurement around traceable measurements, explicit boundaries, geographic context and clearly identified assumptions rather than around one universal figure. That is the difference between a metric designed to provoke concern and a metric designed to support an accountable infrastructure decision.

Scary Metrics Hid The Real Trade-Off. Better Metrics Can Reveal It

The most useful response to a disputed water benchmark is not to replace one broad estimate with another broad estimate, but to establish a measurement structure that identifies the physical boundary, evidence base and assumptions behind each component. The stronger response is to rebuild the measurement so that every important part of the water relationship remains visible, traceable and open to verification. Computing infrastructure consumes water directly through cooling and related operations, while electricity generation can create an additional water burden outside the physical boundary of the computing site. Recent research continues to identify both components as relevant to understanding the water footprint of data centers, while also highlighting limitations in reporting quality and the availability of sufficiently granular data. A more complete accounting method should make that complexity understandable rather than hiding it behind a memorable benchmark.

The water footprint is real, but the measurement must become more precise

The distinction matters because water is fundamentally local even when computing operates globally. Electricity can cross market boundaries, workloads can move between computing locations, and cloud services can abstract physical infrastructure from the customer, yet the water consumed by cooling and electricity generation remains connected to particular physical systems. Research examining data center water use has shown that regional electricity characteristics, cooling systems and climate conditions can materially alter the relationship between computing activity and water consumption. A procurement decision that considers only the water visible at the computing site therefore risks overlooking an important part of the resource chain supporting the workload. A procurement decision that considers only upstream electricity water use would make the opposite mistake by obscuring the operational choices that determine direct consumption.

That approach also changes the role of the benchmark itself. A large rounded estimate can still serve as a useful warning when it accurately describes the conditions under which it was produced, but it should not become a universal substitute for measurement. Public reporting already shows that operators use different boundaries, methodologies and levels of granularity when describing water consumption, while research continues to point to gaps in data availability and attribution. A procurement metric should therefore make uncertainty visible rather than attempt to eliminate it through excessive numerical precision. That means identifying whether an input comes from a meter, a utility record, a documented generation factor, a regional model or an assumption about future operation. Such provenance gives a buyer something more valuable than a memorable number because it makes the result capable of being challenged, updated and compared on consistent terms.

Better measurement makes the trade-off visible

The central question for AI infrastructure is not whether water use should be considered alongside computing growth, because that relationship already exists in the physical systems that provide cooling and electricity. The more important question is whether buyers can identify the water consequences of different infrastructure choices before those choices become difficult to change. A workload hosted in one region can interact with a different cooling environment, electricity system and water basin from the same workload hosted elsewhere, while scheduling can further alter the electricity conditions under which the computation operates. Recent research has increasingly examined workload-level water impacts because facility-level efficiency measures alone do not capture every difference arising from computing performance, utilization and electricity demand. Water accounting becomes more useful when it follows the workload through the systems that make that work possible.

The five-million-gallon figure illustrates the limits of using a single large estimate to represent data-center water demand, because current evidence shows that actual requirements vary with facility scale, cooling technology, climate and local operating conditions. A widely repeated figure can become detached from the assumptions that determine its applicability when the original facility characteristics, cooling configuration and measurement boundary are not retained alongside the number. A better approach does not make the water footprint of AI smaller for the sake of easier headlines, nor does it make the footprint larger simply to create urgency. It makes the accounting more complete by distinguishing direct consumption from electricity-related consumption, separating measured data from modeled inputs and connecting electricity demand with the water systems associated with generation. The real improvement is therefore not a scarier benchmark, but a measurement system capable of showing the trade-offs that the old benchmark concealed.

[simple-author-box]

More from AI Infrastructure

The first indication of a cooling problem can come from measurements within the compute

An AI system can fail without anyone immediately knowing who owns the failure. The

The easiest place to imagine a data center is not necessarily the easiest place

COMPUTE WEEKLY

The briefing that 40,000+ tech leaders read every Monday. Sharp, fast, essential.

Great! We’ve received your information.

Building an AI Startup Without Owning GPUs

Not owning GPUs has become the default, deliberate strategy for building an AI company — not a compromise founders accept reluctantly. H100 rental rates fell 64-75% in fifteen months, a dense ecosystem of neoclouds and inference-as-a-service providers now lets startups skip infrastructure entirely, and credit programs can fund a company’s first year before a founder writes a check
Most Read

AI infrastructure decisions increasingly influence what enterprises can build, test, and deliver. They also

Why Infrastructure Planning Now Starts With Availability A data center project can have a

A property can look enormous from the site entrance and still offer almost no

As rack power rises toward the megawatt range, the physical footprint of power-delivery equipment

A data center project can look complete long before it delivers usable capacity. The

Disruptor Spotlight

Cerebras Systems

The chip that makes Nvidia nervous. Cerebras’ Wafer Scale Engine is rewriting the rules of AI inference at scale.
Faster
0 x
YoY Revenue
0 x
Transistors
0 T
Market Pulse
MSFT
+1.02%
NVDA
+0.66%
AMZN
-0.078%
AMD
-6.95%
TSMC
-2.98%
Indicative only · Not financial advice
Upcoming Events
SEP
The AI Infrastructure Race (India)
WEBINAR · ONLINE
The AI Infrastructure Race: Won on Power, Land and Trust — Not Capital
MAY
0
AI Infrastructure Summit
DUBAI · IN PERSON
MEA’s premier AI infrastructure event.
JUN
0 0
Compute Forecast Summit
SINGAPORE · IN PERSON
Our flagship APAC event. Early bird open.
Latest Moves
Live
ecolab
Ecolab Deepens Cooling Strategy With $4.75B CoolIT Acquisition
Ecolab is making one of its biggest moves yet into AI infrastructure after completing its $4.75 billion acquisition of liquid cooling specialist CoolIT Systems
Pure DC AVK Europe data center microgrid Dublin 110MW AI infrastructure Ireland 2026
Pure DC and AVK Deploy Europe’s First 110 MW Data Center Microgrid in Dublin
The Pure DC Dublin microgrid has made history as Europe’s first large-scale on-site data center microgrid, launched in partnership with power solutions provider AVK at Pure DC’s campus in Ireland.
Pace Digitek
Pace Digitek Partners With MEGMEET to Expand AI Data Center Power Business
India’s AI infrastructure ecosystem continues to mature as domestic technology manufacturers move beyond traditional telecommunications and industrial markets toward high-growth digital infrastructure opportunities
Follow Compute Forecast
11K followers
1200 followers
Companies to Watch
CW
CoreWeave
Neo Cloud · $19B · IPO Watch
CB
Cerebras Systems
AI Hardware · $4.25B · Pre-IPO
G42
G42
Sovereign AI · Abu Dhabi
H
Humain
Saudi AI · $40B Fund
Latest Podcast
AI Capex, Cloud Margins & the Nuclear Bet
48 MIN · 25 APR 2026

The Million-Gallon Benchmark Is Not Enough. What Metric Should Replace It?

A large round number has a peculiar ability to become infrastructure folklore. Once a water-use estimate enters public discussion, it

Share
Full-Stack Water Score
2
847 SHARES

0
SHARES

[simple-author-box]

More from AI Infrastructure

AI infrastructure decisions increasingly influence what enterprises can build, test, and deliver. They also

Why Infrastructure Planning Now Starts With Availability A data center project can have a

A property can look enormous from the site entrance and still offer almost no

As rack power rises toward the megawatt range, the physical footprint of power-delivery equipment

COMPUTE WEEKLY

The briefing that 40,000+ tech leaders read every Monday. Sharp, fast, essential.

Great! We’ve received your information.

Global AI Infrastructure Outlook 2026

The briefing that 40,000+ tech leaders read every Monday. Sharp, fast, essential.
Download Free
Most Read

AI infrastructure decisions increasingly influence what enterprises can build, test, and deliver. They also

Why Infrastructure Planning Now Starts With Availability A data center project can have a

A property can look enormous from the site entrance and still offer almost no

As rack power rises toward the megawatt range, the physical footprint of power-delivery equipment

A data center project can look complete long before it delivers usable capacity. The

Disruptor Spotlight

Cerebras Systems

The chip that makes Nvidia nervous. Cerebras’ Wafer Scale Engine is rewriting the rules of AI inference at scale.
Faster
0 x
YoY Revenue
0 x
Transistors
0 T
Market Pulse
NVDA
$924.60
+2.4%
MSFT
$421.30
+1.1%
AMZN
$192.80
-0.6%
NVDA
$924.60
+2.4%
NVDA
$924.60
+2.4%
Indicative only · Not financial advice
Upcoming Events
MAY
0 0
DCD Global — London
LONDON · IN PERSON
World’s largest DC event. CF is media partner.
MAY
0
AI Infrastructure Summit
DUBAI · IN PERSON
MEA’s premier AI infrastructure event.
JUN
0 0

Compute Forecast Summit

SINGAPORE · IN PERSON
Our flagship APAC event. Early bird open.
Latest Moves
  • Live
Sam Altman
OpenAI appoints new Chief Infrastructure Officer to lead $100B DC programme
27 APR · OPENAI
Sam Altman
OpenAI appoints new Chief Infrastructure Officer to lead $100B DC programme
27 APR · OPENAI
Sam Altman
OpenAI appoints new Chief Infrastructure Officer to lead $100B DC programme
27 APR · OPENAI
Follow Compute Forecast
18.4K followers
12.1K followers
9.3K subscribers
41 episodes
Companies to Watch
CW
CoreWeave
Neo Cloud · $19B · IPO Watch
CB
Cerebras Systems
AI Hardware · $4.25B · Pre-IPO
G42
G42
Sovereign AI · Abu Dhabi
CW
Humain
Saudi AI · $40B Fund
Latest Podcast
AI Capex, Cloud Margins & the Nuclear Bet
48 MIN · 25 APR 2026
Scroll to Top
Seraphinite AcceleratorOptimized by Seraphinite Accelerator
Turns on site high speed to be attractive for people and search engines.