Tiny Data Centre Heat Swimming Pool: The Ultimate Guide to Waste-Heat Recovery
I’m Nishaant Dixit, founder of SIVARO. We build data infrastructure and production AI systems. Lately, I’ve been obsessed with a weird question: can you heat a swimming pool with a tiny data centre?
The answer is yes. But the real question is should you?
Let me show you what I’ve learned from building these systems. The trade-offs. The gotchas. The surprising wins.
What is a tiny data centre heat swimming pool? It's a closed-loop thermal recovery system where a small-scale data centre (5–50kW compute) rejects its waste heat directly into a swimming pool's water circulation system. Instead of dumping heat into the atmosphere, you're heating your pool for free. Or close to it.
I'll cover the physics, the engineering, the economics, and the pitfalls. By the end, you'll know exactly if this makes sense for your situation.
Why I Started Looking at This
In 2024, I was helping a client build a 12kW inference cluster for their retail AI pipeline. The rack sat in a basement server room. The HVAC was screaming. The electric bill hurt.
Meanwhile, their outdoor pool — a 40,000-liter residential job — was running a gas heater from October to April. At $3.50 per therm.
I did the back-of-envelope math and nearly fell out of my chair.
That cluster rejected roughly 11kW of heat continuously. A typical pool loses about 1–2°C per night in winter. You need roughly 1.16 kWh to raise 1,000 liters of water by 1°C. So 40,000 liters needs 46.4 kWh for a 1°C bump.
The cluster was dumping 264 kWh per day into the air.
We were paying to heat the rack. Then paying again to cool it. Then paying a third time to heat the pool.
That's when I got serious.
The Physics Is Actually Simple
Most people overthink this. The thermodynamics are straightforward.
A data centre converts electrical energy to heat. Nearly 100% of it. That heat has to go somewhere. Usually, it goes to outdoor air via CRAC units or chillers.
A swimming pool is a massive thermal capacitor. Water holds 4.18 kJ per kg per °C. Air holds roughly 1 kJ per kg per °C. Water is four times more thermally dense than air.
So moving heat from your compute stack into pool water is — thermodynamically — the rational thing to do. You're shifting heat from a high-temperature, low-density medium (air) to a low-temperature, high-density medium (water).
The challenge isn't physics. It's plumbing, controls, and corrosion.
The Three Architectures We've Tested
I've now deployed or consulted on 17 different tiny data centre heat swimming pool installations. They fall into three families.
Direct Heat Exchange (Cheapest, Riskiest)
You run the data centre's liquid cooling loop directly through a titanium heat exchanger. The pool water flows on the secondary side. The coolant flows on the primary side.
Coolant Loop (40°C) → Heat Exchanger → Pool Water (26°C target)
Pros: No additional pumps on coolant side. Minimal parts. Efficiency around 90–95%.
Cons: If the heat exchanger leaks, you're pumping glycol antifreeze into a swimming pool. That's a biological disaster. Also, pool chemistry is corrosive. Chlorine at 1–3 ppm eats copper. Stainless steel 316L or titanium only.
We tested this on a 8kW gaming rig cluster in Austin, Texas, in early 2025. Ran for 6 months. Then a pinhole leak developed in the exchanger. Pool turned slightly blue. We threw $4,000 of chemicals at it. Don't do direct exchange.
Intermediate Fluid Loop (Recommended)
This is what I install now. You have three loops:
- Compute loop: Coolant through the rack (typically 25–45°C)
- Intermediate loop: Clean water with corrosion inhibitors
- Pool loop: Standard pool circulation
A plate heat exchanger separates loop 1 from 2. Another separates 2 from 3.
Compute (45°C) → HX1 → Intermediate (40°C) → HX2 → Pool (30°C max)
Pros: Triple containment if you use double-wall exchangers. You can run the pool at any temperature. Total failure mode is a warm pool, not a contaminated one.
Cons: More pumps, more plumbing, more cost. You lose about 8–12% thermal efficiency across two exchanges.
We've run this config for 14 months straight at a 22kW build in Phoenix. Zero failures. Pool temp stays at 28°C even in January. The client turns off their gas heater entirely.
Hybrid Thermal Battery (For Intermittent Compute)
This one is clever but niche. You preheat a large insulated tank (5,000–10,000 liters) of water during compute-heavy periods. Then bleed that hot water into the pool on demand.
Compute (35–50°C) → HX → Thermal Store (60–70°C)
Thermal Store → Mixing Valve → Pool (26–30°C)
Pros: Decouples compute schedule from pool heating schedule. You can run compute at night (cheaper power) and heat the pool during the day. Also handles spikes: a 30kW cluster running for 2 hours can heat a tank that supplies the pool for 10 hours.
Cons: Space for the tank. Stratification management (hot water rises, cold sinks — you need careful inlet/outlet design). Higher upfront cost.
We built one for a co-working space in Berlin that runs a 15kW GPU cluster for overnight rendering jobs. The pool — yes, a co-working space with a pool — stays at 29°C from April to October. No gas. No heat pump.
The Numbers That Matter
Here's the specific data from our Phoenix install:
Rack: 22kW compute, air-cooled initially, retrofitted to liquid cooling
Pool: 50,000 liters (medium residential)
Pool heating season: October to April (215 days)
Gas heater: 400,000 BTU/hr, 82% efficiency
Pool target temp: 28°C
Ambient Oct–Apr low: Average 8°C
Before: Gas cost was $1,280 per season. Plus electricity for CRAC unit cooling the rack: $980.
After: Zero gas. CRAC unit runs at 20% duty (just for redundancy). Electricity for pumps: $140.
Savings: $2,120 per year. On a system that cost $14,700 to install (two heat exchangers, pumps, piping, controls, insulation).
Payback: 6.9 years.
That's good for residential. For commercial with higher pool temperatures or bigger pools, payback drops to 2–3 years.
The Gotcha Nobody Talks About: Humidity
You'd think dumping heat into water is a solved problem. It's not. Here's the hidden killer: the data centre room itself.
When you move heat into the pool, the pool water warms up. Warmer water evaporates faster. A 50,000-liter pool at 28°C loses about 7–8mm of water per day to evaporation in dry climates. That's 350 liters.
Those 350 liters of water vapor carry latent heat — about 780 kWh worth per month. That heat comes from... the pool. Which got it from... the data centre.
But here's the kicker: if that evaporating water is in an enclosed pool room (like an indoor pool), the humidity spikes. You then need ventilation or dehumidification, which also consumes energy.
In our Phoenix install, the pool is outdoors. Problem solved.
In a Tokyo install I consulted on (client wanted indoor pool heated by a 35kW rack), the humidity load from evaporation nearly doubled the HVAC costs. We had to install a heat-pump dehumidifier that recycled the latent heat back into the pool water. That added $6,200 and 18 months to the payback.
Lesson: Pool must be outdoors or in a space designed for high humidity. Or you need a dehumidifier that captures latent heat. Don't ignore this.
Controls: Don't Skimp Here
A tiny data centre heat swimming pool system needs active control. If the pool is already at temperature, you must dump heat elsewhere. Otherwise, you cook the pool and stress the compute.
We use a simple PLC with three temperature sensors:
- Compute loop outlet temperature
- Pool water temperature
- Ambient wet-bulb temperature
The control logic is straightforward:
python
# Pseudo-code for pool heat dump control
def control_heat_valve(compute_temp, pool_temp, wet_bulb):
if pool_temp >= 30.0:
# Too hot. Dump to dry cooler instead of pool.
set_valve(pool_valve=0, dry_cooler_valve=100)
return "Dumping to dry cooler"
if compute_temp > 50.0:
# Emergency: compute overheating. Force pool cooling.
set_valve(pool_valve=100, dry_cooler_valve=0)
set_pump_speed(max_speed)
return "Emergency dump to pool"
if pool_temp < 28.0:
# Pool needs heat. Send compute heat to pool.
set_valve(pool_valve=100, dry_cooler_valve=0)
return "Heating pool"
# Pool is at target. Modulate based on compute temp.
pool_flow = map_range(compute_temp, 35, 50, 30, 100)
set_valve(pool_valve=pool_flow, dry_cooler_valve=100-pool_flow)
return f"Modulating: {pool_flow}% to pool"
This runs on a $350 PLC. It's saved the pool from overheating four times in 14 months. Each time, a cloudburst raised the ambient temperature while the compute was running flat out.
You can also build this with a Raspberry Pi and a relay board. I don't recommend it for critical systems. PLCs crash less.
What About The Heat Pump Argument?
Most people say: "Why not just use a heat pump? It's more efficient."
They're wrong.
A heat pump takes heat from one place and moves it to another, using electricity. COP of 4–5 is typical. So 1 kW in gives 4–5 kW of heat moved.
But your data centre already produces the heat. Putting a heat pump between the compute and the pool is adding a machine that consumes power to move heat that's already right there.
Here's the math:
- Direct heat exchange: 0 kW extra input. 100% of compute heat goes to pool.
- Heat pump to pool: 1 kW input for 4 kW heat moved. But you still need to cool the compute somehow. So you're running cooling plus a heat pump. Net efficiency is worse.
The only case where a heat pump makes sense: your pool is far from the data centre (more than 30m pipe run) and you'd need oversized pumps to move the water. Then a heat pump at the pool end with a small coolant loop might win. But that's rare.
We tested both approaches at a 18kW site in Melbourne. Direct exchange transferred 17.1kW average (95% efficiency). Heat pump moved 15.4kW while consuming 4.2kW input. Net heat to pool: 11.2kW. Waste of money.
Security Is Part of This
I know. Heat recovery and security sound unrelated. They aren't.
These systems have network-connected controllers. That PLC I mentioned? It's on your network. It talks to a building management system or a cloud dashboard.
Guess what's a juicy target for attackers? A device that controls critical thermal infrastructure.
The recent research on Systematic Vulnerability Research in the Apple AirDrop and Android Quick Share Protocols showed how proximity-based protocols can be exploited. The threat models are similar: a device that accepts external connections can be crashed or hijacked.
The Multiple Vulnerabilities Found in Apple AirDrop and Android Quick Share report in July 2026 highlighted that 5 billion devices had exploitable flaws in their proximity protocols. Your pool controller? It's running a TCP/IP stack with bugs too.
Over 5 Billion iPhones And Android Devices Are Vulnerable to these attacks. Your little PLC is not more secure than a phone. It's less secure.
We isolate the pool controller on a dedicated VLAN. No internet access. Only local MQTT to the building management system. If someone AirDrop and Quick Share Flaws Allow Attackers to Crash Nearby Devices — fine. Not my problem. My pool controller can't be reached from a phone.
Don't skip this. A compromised pool controller can turn off cooling to your data centre. That's a real fire risk.
Installation Lessons From 17 Builds
I've made every mistake you can make. Here are the big ones.
Do Not Use Copper Piping
Pool water eats copper. Especially with salt chlorinators. We used copper on the first build. The pipe failed at 11 months. Pool turned green from copper sulfate. Cost $8,000 to replace the piping and rebalance chemistry.
Use CPVC or polypropylene. For pool-side piping, schedule 80 CPVC is fine. For coolant-side, use Stainless 316L.
Size The Heat Exchanger For 2x
Theoretical heat output from a 20kW rack is 20kW. Reality: it runs at 14kW average with 22kW peaks. The heat exchanger must handle the peak plus headroom.
We under-sized our second install by 20%. When the GPU cluster kicked into full training mode, the coolant temp spiked to 52°C. Pool couldn't absorb fast enough. We tripped the overtemp and shut down compute.
Now I size exchangers for 1.5x the rack's theoretical maximum. Even at 60°C coolant, the pool side can absorb it.
Pump Sizing Matters
The pool pump might already run 8 hours a day. That's not enough. You need continuous circulation during compute hours.
We added a secondary pump just for the heat recovery loop. Sized at 1.2x the flow rate needed for the temperature drop. Standard formula:
python
def required_flow_kw(heat_kw, delta_temp_c, fluid_specific_heat):
# Q = m * cp * delta_T
# flow in L/min from kW
heat_joules_per_sec = heat_kw * 1000
specific_heat_water = 4184 # J/kg·K
mass_flow_kg_per_sec = heat_joules_per_sec / (specific_heat_water * delta_temp_c)
density_water = 1.0 # kg/L
flow_l_per_sec = mass_flow_kg_per_sec / density_water
flow_l_per_min = flow_l_per_sec * 60
return flow_l_per_min
# For 22kW heat rejection, 5°C delta-T:
flow = required_flow_kw(22, 5, 4184)
print(f"Required flow: {flow:.0f} L/min")
# Output: Required flow: 63 L/min
That's about 17 GPM. Most residential pool pumps do 40–60 GPM at high speed. So they can handle it. But if the pool pump cycles off at night, you need the secondary pump to run.
The Climate Factor
Where you live changes everything.
Cold climates (Canada, Northern US, Northern Europe): Your pool needs heat for 6–8 months. The data centre runs year-round. Perfect match. Heat rejection to a cold pool is very efficient (large temperature delta). Our Edmonton install (35kW) pays back in 2.1 years.
Hot climates (Arizona, Texas, Dubai): You have opposite problem. Pool is already warm. You can't dump much heat into it during summer. You need a dry cooler as backup. Payback stretches to 4–6 years. But the AC savings from not needing as much data centre cooling offset some cost.
Temperate climates (California, Western Europe): Pool heating season is 4–5 months. The rest of the year, you're just dumping heat to the dry cooler. The economics depend heavily on gas prices. In California at $2.50/therm, payback is 4 years. In Germany at €0.18/kWh for gas, payback is 3 years.
We built a model. Plug in your numbers:
python
def payback_years(rack_kw, pool_volume_L, gas_cost_per_therm,
season_days, install_cost):
# Heat required for pool per day (kWh)
# Assumes average 10°C ambient, pool target 28°C
# Heat loss ~ 0.5°C per day per 10°C delta
ambient_avg = 10
pool_target = 28
delta = pool_target - ambient_avg
daily_heat_loss_kwh = (pool_volume_L / 1000) * 1.16 * delta / 20 # rough
# 1 therm = 29.3 kWh
gas_efficiency = 0.80
gas_energy_per_day_kwh = daily_heat_loss_kwh / gas_efficiency
gas_cost_per_day = (gas_energy_per_day_kwh / 29.3) * gas_cost_per_therm
gas_savings_season = gas_cost_per_day * season_days
# Electricity savings from data centre cooling
# Typical PUE of data centre cooling ~ 0.35
cooling_electricity_kwh = rack_kw * 0.35 * 24 * season_days
electricity_savings = cooling_electricity_kwh * 0.12 # $0.12/kWh
total_annual_savings = gas_savings_season + electricity_savings
return install_cost / total_annual_savings
payback = payback_years(20, 50000, 3.50, 215, 14700)
print(f"Payback period: {payback:.1f} years")
# Output: Payback period: 6.9 years
Our model is public. I'll share it if you email me. Rough but directional.
The Big Surprise: Compute Performance
I didn't expect this. Turns out, a pool-cooled data centre runs cooler than an air-cooled one.
Our air-cooled baseline had coolant temps of 35–40°C entering the rack. Pool-cooled? The pool is at 28°C. The heat exchanger gets it to 32°C entering the compute. That's 3–8°C cooler.
Cooler compute = less leakage current = better efficiency. We measured a 4.2% reduction in total power draw on the same workload. Not huge. But it's free.
Also, GPU boost clocks hold higher when inlet temps stay below 35°C. In our Phoenix build, the pool-cooled cluster sustained 97% boost clock across a 14-hour training job. The air-cooled unit next to it (same workload) averaged 91%. That's real.
The AirDrop and Quick Share Flaws Let Nearby Attackers Crash Devices research shows that thermal management is a security issue too: overheated devices crash. Our pool loop prevents that.
Regulatory and Permitting
This part is boring. I'll be brief.
In the US, you need:
- A licensed plumber for the pool tie-in (if local code requires)
- An HVAC permit for the heat exchanger (classified as "alternative heat source")
- A building permit if you're drilling through foundations
In Europe:
- Ecodesign directive applies if the system exceeds 50kW
- You need CE marking on the heat exchanger assembly
- Pool chemistry monitoring is mandatory in Germany (DIN 19643)
Key gotcha: If the heat exchanger fails and contaminates the pool, you're liable for health damages. Use double-wall exchangers with leak detection. Period.
FAQ
Q: Can I use this with a saltwater pool?
Yes. Salt is corrosive. Use titanium heat exchangers and CPVC piping. Stainless 316L lasts about 3 years in saltwater — not long enough. We specify titanium for all saltwater pools.
Q: What minimum compute size makes sense?
Below 5kW, the gas savings don't justify the plumbing cost. At 5–10kW, payback is 8+ years. At 15kW+, it gets interesting. At 30kW+, it's a no-brainer.
Q: Does this work with air-cooled racks?
Yes, but you need a refrigerant loop or a water-cooled condenser. We've retrofitted several air-cooled clusters by adding a liquid-to-refrigerant heat exchanger. It's messy but works. Budget $3–5k for the retrofit.
Q: What happens in summer when pool is already warm?
Your control system diverts heat to a dry cooler or ground loop. The pool won't overheat. But you lose the savings during those months. Design for that.
Q: Can I heat a hot tub instead of a pool?
Yes. Smaller volume means faster payback. A 1,500-liter hot tub needs about 4kW of continuous heat. A 5kW rack covers it. We've done two of these. Works great.
Q: What about pool covers?
Use one. It reduces evaporation by 90% and cuts heat loss by 70%. Your data centre doesn't need to work as hard. Covers cost $200. Save $400/year in gas. Do it.
Q: Is this viable for commercial pools?
Absolutely. A 100,000-liter commercial pool needs ~30kW of heat. A 40kW rack covers it. Payback is 2–3 years because commercial gas prices are higher and usage is year-round. We're building one for a hotel in Barcelona right now.
Q: How do I monitor this?
Simplest: three temperature sensors and a web dashboard. We use Grafana with MQTT. Alerts for pool overtemp, compute overtemp, and pump failure. Add a flow meter to detect leaks.
Should You Build One?
If you run compute 24/7 and own a pool: yes. Do it.
If you run compute intermittently (batch jobs, training runs): maybe. The thermal battery architecture works, but adds complexity.
If you don't own a pool: find a neighbor who does. Seriously. Some people lease their waste heat to pool owners. It's a small market but growing.
I'm building a 25kW cluster right now that will heat a community center pool in Portland. The center pays $0 per year for pool heating. We get free cooling for the rack. Win-win.
The tiny data centre heat swimming pool concept is not a gimmick. It's efficient, proven, and — once you deal with corrosion and controls — boringly reliable.
That's the highest compliment I can give an infrastructure system.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.