The Real Constraint on Data Centers in Space

The year it stopped being crazy

Every few years someone proposes putting data centers in space, engineers explain why it will not work, and everyone moves on. In 2025 the hardware actually flew, and the people paying for it are not hobbyists.

In November 2025 a startup called Starcloud put a 60 kg satellite carrying an Nvidia H100 into orbit and trained a language model on Shakespeare's complete works from 350 kilometers up. It was the first time a current data center GPU had run in space.

A few weeks later Google announced Project Suncatcher: TPUs in orbit by 2027, and a longer-term design for 81-satellite clusters linked into an orbital compute grid. It came with a technical paper and a launch date.

Jeff Bezos told Italian Tech Week that gigawatt data centers in space would undercut terrestrial ones on cost within 10 to 20 years. Elon Musk said SpaceX would get there by scaling up Starlink V3 satellites. Eric Schmidt bought Relativity Space and said the purpose was to build orbital data centers.

Three of the richest people on Earth, plus Google, made the same bet in the same year. Some of it is keynote talk and some of it is funded hardware. We would not build a plan around a Bezos speech, but when the people who own the rockets and the chips both point the same way in the same year, the engineering deserves a serious look.

Why smart people keep coming back to this idea

Before the hard problems, it is worth being clear about why serious people keep coming back to this. The advantages are physics, and they are large.

Start with power

Above the atmosphere the sun delivers about 1,361 watts per square meter, with no clouds and no weather in the way. In a dawn-dusk sun-synchronous orbit at 650 kilometers a satellite sees sunlight more than 95% of the time, and a panel there produces roughly 8 times the energy of the same panel on a rooftop in Arizona. Batteries and power conditioning add mass and eat into some of that advantage, but generation itself is not the constraint.

That matters because power is what is holding AI infrastructure back on the ground right now. Utilities are telling hyperscalers to come back in 2028, and permitting a new site near a population center takes years. Eric Schmidt testified to Congress that data centers could need another 67 gigawatts by 2030, and argued that collecting solar energy in orbit might be the only way to get there.

Launch costs have collapsed

Google's analysis puts the crossover at about $200 per kilogram: at that price, launch cost amortized over a satellite's life is roughly equal to the energy bill for the same compute on Earth. Below that price, “free solar” starts to mean something.

Radiation survivability is improving, but survivability is not reliability

Google put TPU v6 chips in a proton beam that simulated five years of low Earth orbit radiation. They took up to three times the expected dose without a hard failure. The high-bandwidth memory threw errors above certain thresholds, which error correction can handle for many workloads. The old rule that everything in space needs an expensive rad-hardened processor is loosening.

We think the radiation risk still gets understated, though. A cosmic ray hit that kills a chip outright is the easy case. The harder case is slow analog drift, which resists modeling: transistor threshold shifts, SRAM bit flips, PLL instability, timing skew. Those accumulate over years, and the symptoms show up as training runs that stop converging, long jobs that fail more often, and ECC overhead that keeps climbing. None of that is solved. It is one more reason you need to watch every chip closely and predict when it will go.

Permitting is simpler

There are no NIMBY fights in orbit, no zoning hearings, no water rights disputes, and no interconnection queue. You still need the FCC and the FAA, but you skip the years of local permitting that stall terrestrial projects.

The thermos problem

If the goal is cheap cooling and no land fights, why not put the servers in the ocean? Microsoft tried it with Project Natick, and the underwater servers failed at one-eighth the rate of the same hardware on land. But Natick still had to haul a module to the surface to fix anything. In orbit you cannot even do that, and that difference matters more than almost anything else in this article. It starts with a bit of physics most people get backwards.

Ask most people how hard it is to cool something in space and they will tell you space is cold. It is not, in any way that helps you. Space is a vacuum, and a vacuum is an insulator: it is the reason a thermos keeps coffee hot. An orbital data center is a server running inside a very large thermos.

On Earth you move heat with air, with water through a heat exchanger, or with an evaporative tower. None of those work without a fluid around you. The only way to reject heat in a vacuum is to radiate it: point large panels at deep space and let them emit infrared.

How much a surface radiates is set by the Stefan-Boltzmann law, which ties radiated power to temperature. A blackbody (an ideal surface that radiates as well as physics allows) at 45 degrees Celsius sheds about 520 watts per square meter; at 15 degrees, about 390. Real radiators do worse. Once you account for emissivity below 1, view factor losses, panel geometry, dust, shadowing, and thermal control margin, usable rejection lands closer to 100 to 350 watts per square meter. The area that implies is large:

For scale, the International Space Station rejects about 75 to 90 kilowatts with roughly 2,500 square meters of radiator. That is the whole station, life support for six astronauts included. One high-density AI rack on Earth can pull 50 kilowatts on its own.

Radiators that size are also heavy, fragile, and a big target for debris. They cycle from about minus 100 degrees Celsius in shadow to plus 120 in sunlight every 90 minutes, and they have to keep doing that for years.

Cooling is solvable, but it dominates the design. Look at any rendering of an orbital data center and most of what you are seeing is radiator. The thing is closer to a power plant that does some computing on the side than to a server room in orbit.

That is why the coolant temperature trend matters so much. Data center GPUs from both Nvidia and AMD now tolerate much warmer coolant than they did a decade ago:

In 2014 the Tesla K80 throttled unless its coolant stayed below 15°C. In 2026 Vera Rubin runs on 45°C coolant, three times the tolerance in a little over a decade. Jensen Huang made the point at CES: at 45°C no water chillers are necessary, and the system can run on warm water and ordinary dry coolers even in a hot climate.

The density trap

The catch is that power density is rising faster than coolant tolerance.

TDP over the same GPU generations:

From 2014 to 2020 TDP sat at 300 to 400 watts. Then it jumped to 700 watts with H100, went past 1000 watts with Blackwell, and is projected to reach 1500 to 1800 watts with Vera Rubin. In six years, power per chip went up roughly 5 to 6 times.

Rack density tells the same story. A CPU rack ran at 10 to 15 kilowatts. An H100 rack runs at 50 to 70, a GB200 NVL72 at 132, and NVIDIA's roadmap has 240 kilowatt racks next, with 1 megawatt rack designs already shown at OCP 2025.

Performance per watt keeps improving, and every gain gets spent on more compute rather than less power. Terrestrial economics reward density: customers want more compute per rack and more revenue per square foot, so vendors pack more into the same footprint. Model scaling pushes in the same direction. If chips get twice as efficient and models get four times bigger, power density still goes up.

This hurts more in orbit than on the ground. On Earth, high density is a nuisance you buy your way out of with bigger chillers and thicker cable. In orbit nothing is externalized: every watt has to be generated, stored, moved, and radiated on the same vehicle. Space does not care about your FLOPs per watt. It cares about watts per kilogram and watts per square meter, and both are moving the wrong way.

So the two curves fight each other. Coolant tolerance improved about 3x, which makes each square meter of radiator more useful. Power per chip went up about 6x, which means far more heat to shed. Net, cooling stays the dominant engineering problem, and the radiator area you launch is the radiator area you have for the life of the vehicle.

Space does have one thing Earth does not: power to spare. A panel in orbit generates 5 to 10 times more energy than the same panel on the ground. Solve the thermal problem and generation stops being the limit. The question becomes how many watts you can afford to lift per kilogram, rather than how many FLOPs you get per watt.

Our guess is that the design that wins looks nothing like a hyperscale platform trailing a kilometer of radiator. It looks like a lot of small, low-power nodes, sized around thermal limits rather than compute density, and flown as a constellation so individual satellites can be replaced as they fail or go obsolete.

The problem nobody is solving

Now the one underneath all the others: maintenance. On Earth a failed server gets swapped and a dead pump gets a technician. In orbit, neither happens.

People blur two separate constraints here. Repairability: when hardware fails, you cannot fix it. Upgradability: when it goes obsolete, you cannot swap it. A terrestrial data center does both as routine work. Either one on its own breaks the standard data center financial model.

Starcloud-1, the H100 satellite, has an expected operating life of 11 months. Then it deorbits and burns up. Google says as much in the Suncatcher paper: since you cannot replace a failed TPU in space, the simplest answer is redundant provisioning. Launch spare capacity and hope you do not need all of it.

Everything downstream follows from that: asset lives of 3 to 5 years instead of 5 to 7, a technology generation frozen at launch, failures that are all or nothing, and debris events that can take out several satellites in a constellation at once.

Software is under the same rule. A bad firmware image, a control plane bug, a broken scheduler, a breach, or a botched update rollout is just as terminal as a dead board. On Earth you SSH in and restart the hung process. In orbit, if the watchdog does not catch it, you own a very expensive paperweight. You cannot fix hardware, and you cannot fix mistakes either.

When you cannot repair, prediction becomes everything

On the ground you can afford to be reactive. Something breaks, you fix it, and a failed drive costs a new drive plus a few hours of a technician's time.

In orbit there is no reactive maintenance. The only strategy is prediction: catch problems before they become failures, and design for the failures you cannot catch.

That changes what telemetry is for.

On Earth, hardware monitoring is useful but optional. Plenty of operators run minimal telemetry and replace things when they break, and the economics work fine.

In space it is existential. You need to know:

• Which components are starting to degrade
• How much thermal margin is left
• Whether radiation dose is accumulating faster than planned
• When to move workloads off failing hardware, before it dies
• When to launch replacements so capacity does not drop below what the business needs

That is a different operating model from terrestrial monitoring, one where prediction accuracy decides whether the business works at all.

We already see a version of this in terrestrial GPU fleets. Identical hardware ages at very different rates depending on workload, thermals, and utilization. A GPU holding steady inference at 65% utilization and one spiking to 100% for training every afternoon are not the same asset a year later, and the gap can be years of useful life.

Orbit makes that gap expensive. Every satellite will need per-chip health monitoring, and the operators with the best prediction will have the lowest real cost per unit of compute. The ones flying blind will watch satellites die early with the capital still on them.

The companies building these models on terrestrial fleets are building the ability to predict a failure weeks or months out, from the relationship between the upstream plant and the downstream asset. That is the problem we work on at Aravolta every day. The same models that give a lender a GPU depreciation curve, or give an operator a way to stretch asset life, apply directly in orbit, with much higher stakes.

Now the speculative part: what if prediction gets good enough that repair starts to pay?

Today the assumption is that orbital hardware is disposable. But if you know with confidence that a particular cooling pump will fail in 90 days, a repair mission starts to pencil differently. SpaceX is working on crewed Starship, Blue Origin on commercial stations, and the cost of putting a technician in orbit is falling with everything else.

Picture orbital platforms built from swappable modules, with a repair crew visiting once a quarter to replace the parts telemetry flagged months earlier. It sounds like science fiction, but so did landing a booster fifteen years ago. Even then, repair only works if prediction is close to perfect, because you cannot send a crew to fix something you did not know was breaking. The constraint moves from “repair is impossible” to “prediction has to be very good,” which is the same conclusion from the other direction.

What to watch

If you are looking at orbital compute as an investor, an operator, or a customer, these are the signals we would track:

Starship economics. Nearly every positive business case assumes SpaceX gets close to its cost targets. At $200 per kilogram the numbers change. Stalled at $1,000 per kilogram, orbital compute stays an expensive niche.

Thermal system reliability. The radiator and cooling loop are where projects will live or die. Anyone can buy solar panels. Shedding megawatts by radiation while surviving thermal cycling and micrometeorites is hard engineering, and the number to watch is how long a demonstration mission runs against its design life.

Constellation versus monolithic architecture. Google's Suncatcher uses clusters of many small satellites that can be replaced one at a time. Starcloud is planning larger individual platforms. Distributed fails more gracefully and upgrades more easily; monolithic may be more thermally efficient. Nobody knows yet which wins.

Predictive maintenance. The operators with the best telemetry and prediction will have the lowest costs. Look for teams that treat monitoring as core engineering rather than an afterthought, and that track actual workload intensity and thermal stress per asset instead of assuming fleet averages.

Demonstration mission longevity. Starcloud-1 is designed for 11 months. Google's first satellites launch in 2027. How long they actually run in good health will say more about the real depreciation curve than any whitepaper.

So where does this leave us?

Orbital data centers are no longer a thought experiment. Hardware is flying and the launch economics get closer every year.

The deciding constraint is not power, cooling, radiation, or launch cost. It is repair. Every other problem on the list can be engineered around with enough money and a good design. That one cannot, and it rewrites the operating model: shorter asset lives, more redundancy, a frozen technology generation, and all-or-nothing failures.

Latency is structural too. Low Earth orbit adds 20 to 40 milliseconds round trip and geostationary adds 600, and there is no engineering fix for the speed of light. Add Doppler from satellites moving at 7.5 km/s, handover jitter between satellites, and variable routing delay, and latency-sensitive inference cannot compete. Orbital compute will do training and batch work, not answer questions in real time.

There is a data gravity problem on top of the latency one. Hauling petabytes of terrestrial data up to orbit is inefficient, so the compute has to go where the data is generated.

Where it makes sense: processing data that is already in space (Earth observation, where you skip the downlink), defense workloads that need compute nobody can physically reach, batch AI training that tolerates the latency, and jurisdictions where terrestrial build is blocked. Where it does not: general-purpose cloud, real-time inference, and anything that needs consistent low latency or a regular hardware refresh.