30–80 kW per rack sits in an awkward middle ground.
It’s high enough that “more airflow” stops being a universal answer—but not always high enough to justify redesigning every server into a liquid-cooled platform. That’s why most real-world projects end up comparing two very different approaches:
RDHx (rear-door heat exchangers): remove heat at the rack exhaust.
Direct-to-chip (D2C): remove heat at the CPUs/GPUs via cold plates and a liquid loop.
This guide is awareness-stage by design: it defines the categories first, then compares them using the criteria that usually matter to project directors and facility/ops teams.
RDHx mounts a liquid-to-air heat exchanger at the rear of the rack. Hot exhaust air passes through the door coil and is cooled before it re-enters the room.
A useful mental model is “liquid at the rack boundary.” Your servers are still air-cooled internally; you’re intercepting the heat at the rack exhaust.
Direct-to-chip replaces (or supplements) air heat sinks with cold plates on the CPUs/GPUs. Coolant circulates through the server, into a rack manifold, and through a coolant distribution unit (CDU) that interfaces with facility heat rejection.
A useful mental model is “liquid inside the IT.” You’re cooling the silicon directly.
Operator and OEM explainers often describe RDHx as an indirect / in-rack approach (augmented air), while direct-to-chip is true chip-level liquid cooling—see Equinix’s overview of these categories in Exploring Liquid Cooling for Next-Gen Business Applications (2023).
Quick comparison matrix (for 30–80 kW racks)
Use this as a starting point—then read the sections below to see what each score depends on.
Criterion | RDHx (rear-door HX) | Direct-to-chip (D2C) |
|---|---|---|
Best-fit rack density band | Stronger for “moderate-to-high” racks where you want to preserve server form factors; performance is condition-dependent | Stronger as densities rise and chip heat flux becomes the limiting factor |
CapEx (qualitative) | Often lower disruption at the rack level; may avoid server-level conversions | Higher integration scope (server liquid loops + CDU + distribution), especially in retrofits |
OpEx (qualitative) | Adds door fan power and hydronics; can reduce room air-side work depending on architecture | Shifts heat to liquid loop; adds pump power + fluid management; can reduce air-side overhead at high density |
Retrofit time & trades | Typically faster, rack-by-rack; mostly mechanical + controls integration | Typically slower, involves IT/server work + fluid distribution + CDU commissioning |
Reliability (risk domain) | Liquid concentrated at rack boundary; still a liquid loop, but outside servers | Liquid enters server domain; relies on fittings, procedures, leak detection, and segmentation |
Serviceability | Rear-door access constraints; door components become service items | Introduces liquid-handling service steps (QDs, purging, monitoring); can be very maintainable when designed for it |
Scaling to >100 kW/rack | Usually becomes a bridge or “residual heat” tool | Usually becomes the primary approach |
Key Takeaway: In the 30–80 kW band, RDHx often wins when the project constraint is time and disruption; direct-to-chip often wins when the constraint is sustained density and thermal headroom.
Cooling density and thermal headroom for RDHx vs direct-to-chip
Why “kW per rack” is only half the story
Two racks can both be “60 kW,” but behave very differently:
Rack A spreads heat across many servers and fans (more forgiving).
Rack B concentrates heat into a smaller number of GPUs (high heat flux at the die).
RDHx interacts primarily with the rack air path (server fans, pressure drop, containment quality). Direct-to-chip interacts primarily with the silicon thermal path (cold plate, coolant flow, CDU control).
That’s the technical reason you’ll see RDHx described as “augmented air” and direct-to-chip described as chip-level liquid.
Practical envelope: what you can safely plan around
Rather than treat RDHx capacity as a single number, it’s better to treat it as a curve driven by air conditions and water conditions. Coolnetpower makes this point explicitly in How much heat can an RDHx remove?—capacity depends on variables like inlet water temperature and approach.
For direct-to-chip, the practical envelope is usually limited by platform readiness (server support, manifold/QD standardization, CDU availability) rather than the basic heat-transfer mechanism.
Rule of thumb for 30–80 kW:
If your constraint is rack air path stability (fan curves, pressure drop, recirculation), direct-to-chip tends to be more predictable.
If your constraint is minimal server changes, RDHx tends to be the fastest way to create headroom.
CapEx and OpEx (qualitative)
You asked for qualitative framing, so this section focuses on the cost drivers that usually show up in approvals.
CapEx: what you actually buy and install
RDHx CapEx drivers typically include:
RDHx doors (and any door-side controls)
Secondary piping to the row or pod
CDUs (if you’re using an intermediate loop)
Valves, strainers/filtration, balancing, metering
BMS/DCIM integration for alarms and trend data
Direct-to-chip CapEx drivers typically include:
Server cold plates (or liquid-ready servers)
Rack manifolds / distribution
CDUs (often a primary integration item)
Secondary piping and headers (often higher density and more segmentation)
Leak detection, isolation/shutoff logic, and commissioning instrumentation
A practical way to compare is: RDHx concentrates CapEx at the rack boundary; D2C moves CapEx into the IT platform and the liquid distribution architecture.
OpEx: what changes in day-to-day operations
RDHx OpEx drivers often include:
Fan energy at the doors (active units)
Pump energy for the RDHx/CDU loops
Coil cleaning and inspection cycles
Spare door components (fans, controls)
Direct-to-chip OpEx drivers often include:
Pump energy and CDU maintenance
Coolant sampling / fluid management
Training and procedure compliance (service steps)
Spare parts strategy for CDU components, QDs, sensors
Depending on your facility architecture, both approaches can reduce or reshape air-side work.
(For readers who want a deeper dive: Coolnetpower’s broader retrofit comparison includes a practical scorecard and density bands; we’ll refer to it again later without re-linking to keep citations clean.)
Retrofit time and required trades
Retrofit speed is usually dictated by two questions:
Do you have to touch the servers?
Can you stage the liquid infrastructure without taking down the hall?
RDHx retrofit: what typically happens
A typical RDHx retrofit looks like:
Rack-level work: replace rear doors with RDHx doors, verify clearances and rear access.
Mechanical: install/extend secondary piping and connect supply/return; add isolation and balancing.
Controls: integrate alarms and telemetry to BMS/DCIM.
Commissioning: leak check, flow verification, control setpoints, and acceptance under load.
Because the change is localized at the rack boundary, RDHx is commonly deployed rack-by-rack, aligned to maintenance windows.
Direct-to-chip retrofit: what typically happens
A typical direct-to-chip retrofit (or a phased liquid-ready deployment) adds:
IT/platform work: cold plates and server liquid path validation.
In-rack distribution: manifolds, dripless quick disconnects, routing.
CDU integration: flow, pressure, temperature control and redundancy.
Commissioning: flushing/purging, fluid quality verification, leak detection logic tests, and staged cutover.
The scope is still manageable—but it requires tighter coordination between facilities, IT, and vendors.
Pro Tip: If you expect a phased migration, treat “rollback” as a design requirement up front. It changes how you segment manifolds, where you place isolation valves, and how you plan your commissioning sequence.
Reliability and risk domains (a better way to talk about “leaks”)
Reliability discussions often stall at “liquid = leak risk.” That’s too broad to be useful.
A better way to evaluate is to map where liquid exists, what fails, and how you isolate and recover.
RDHx reliability: typical risk domains
With RDHx, liquid is generally outside the server chassis. Typical risk domains include:
Door-side connections and hoses
Row/pod manifolds and valves
CDU interfaces (if used)
Condensation control, depending on dew point and operating conditions
Mitigations commonly include dripless quick disconnects, isolation valves, leak detection and alarms, and serviceable fan design (for active doors). Coolnetpower’s retrofit comparison calls these out explicitly as design practices in Rear-door vs In-row vs Direct-to-Chip Liquid Cooling (2026).
Direct-to-chip reliability: typical risk domains
With direct-to-chip, liquid enters the server domain. Typical risk domains include:
Server internal tubing and cold plates
QDs at the server-to-manifold interface
CDU pumps/sensors/controls
Fluid quality drift over time (chemistry, contamination)
OEM explainers emphasize the need for leak detection and fluid management. For example, Vertiv describes quick disconnects, shutoff valves, leak detection approaches, and fluid management practices in its Understanding direct-to-chip cooling in HPC infrastructure (2024).
⚠️ Warning: Don’t compare “leak risk” as a single scalar. Compare leak domains (door/row vs server), detection time, and isolation strategy (how much equipment is exposed if a leak occurs).
Serviceability: what breaks, what gets replaced, and what your technicians have to do
Serviceability matters in two ways:
Planned work (preventive maintenance, inspection, replacements).
Unplanned work (alarms, leak response, component failure).
RDHx serviceability: the “rear access” trade
Typical RDHx serviceability questions:
Does the door design preserve safe rear access and cable management?
What is the maintenance plan for fans/controls (active doors) and coils?
How is door removal or service handled during live operations?
RDHx can be very practical—but it can also turn rear-of-rack access into a first-order operational constraint if not planned.
Direct-to-chip serviceability: service steps shift to liquid handling
Direct-to-chip serviceability questions often include:
Can technicians disconnect/reconnect with dripless quick disconnects and clear procedures?
Are FRUs designed to be replaced without draining an entire row?
How are air purge and post-service validation handled?
Is fluid sampling/testing part of the maintenance plan?
The key is that direct-to-chip can be highly maintainable—but only when the architecture is designed for MTTR, not just peak kW.
A transparent example: Coolnetpower RDHx lineup (published performance points)
Below is a set of approved performance points for Coolnetpower’s chilled-water RDHx lineup, provided for readers building an RFP or sanity-checking capacity/flow/ΔP ranges.
These values are tied to the entering air and water conditions shown in the table.
Model | 015F | 030F | 040F | 060F | 070F |
|---|---|---|---|---|---|
Sensible cooling capacity (kW) | 15.2 | 30.8 | 41.3 | 60.3 | 71.5 |
Rated power (kW) | 0.51 | 0.72 | 0.83 | 0.90 | 0.95 |
Airflow (m³/h) | 3600 | 7250 | 8300 | 9800 | 10000 |
External static pressure (Pa) | 20 | 20 | 20 | 20 | 20 |
Entering air dry-bulb (°C) | 35 | 35 | 35 | 40 | 45 |
Entering air RH (%) | 30% | 30% | 30% | 22% | 17% |
Entering water temp (°C) | 16 | 16 | 16 | 15 | 15 |
Leaving water temp (°C) | 22 | 22 | 22 | 21 | 21 |
Flow (m³/h) | 2.2 | 4.4 | 5.8 | 8.7 | 10.2 |
Pressure drop (kPa) | 53 | 56 | 55 | 51 | 58 |
Unit weight (kg) | 140 | 160 | 145 | 165 | 175 |
Width (mm) | 600 | 600 | 600 | 800 | 800 |
Depth (mm) | 280 | 280 | 280 | 320 | 320 |
Height (mm) | 2500 | 2500 | 2000 | 2000 | 2000 |
Pipe connection size (DN) | DN32 | DN32 | DN32 | DN40 | DN50 |
If you want a broader, non-spec discussion of how RDHx influences facility efficiency, see Coolnetpower’s FAQ-style analysis in Do rear-door heat exchangers reduce server-room PUE?.
Scaling beyond 80 kW today (and why >100 kW usually pushes you to direct-to-chip)
If your roadmap includes sustained >100 kW/rack, direct-to-chip usually becomes the primary approach.
The reason is simple: at that point, the bottleneck is rarely “room cooling capacity.” It’s typically chip-level thermal limits, plus the operational need to control temperatures tightly under fast load swings.
A common migration pattern is:
RDHx as a fast bridge for racks that need headroom now.
Direct-to-chip for the densest AI/HPC racks.
Hybrid patterns where RDHx helps remove residual heat that’s still left in the air path.
Who should choose which (decision rules you can use in a project meeting)
Choose RDHx when most of the following are true:
You need a fast uplift and want to avoid server-level modifications.
Your biggest risk is project timeline and disruption, not ultimate density.
You can extend a chilled-water / secondary loop to the row with acceptable change control.
You can manage rear-access constraints operationally.
Choose direct-to-chip when most of the following are true:
You have high heat flux platforms (GPU-dense racks) where the silicon is the bottleneck.
Your roadmap includes higher sustained densities and tighter thermal control.
You can standardize service procedures (QDs, fluid management, leak response).
You can invest in commissioning discipline and cross-team training.
If you need a blended approach, Coolnetpower’s comparison includes a scored framework and density bands you can adapt (see the Coolnetpower “rear-door vs in-row vs direct-to-chip retrofit comparison” post referenced earlier).
Next steps
If you’re evaluating RDHx vs direct-to-chip for a specific pod, the fastest way to de-risk the decision is to align on a shared checklist:
target rack density now vs in 18–36 months
allowable downtime per rack/pod
facility water temperature regime and controls
leak-domain mitigations (detection + isolation + response)
service procedure requirements and staffing
If you want, we can provide a procurement-friendly RFP field list (capacity points, flow/ΔP ranges, QD standards, redundancy, commissioning tests) tailored to your 30–80 kW racks.
