Compute in orbit has a real niche: processing data that already lives in space. A general-purpose cloud in orbit, the AWS-for-the-web version of the pitch, runs into physics and economics that no amount of launch cadence fixes.

The pitch is now serious money, not science fiction. SpaceX has applied to the FCC for a system of up to one million satellites operating as an orbital data centre, and has claimed it could deliver 100 GW of AI compute. Google published Project Suncatcher, a preprint describing clusters of TPU-carrying satellites in a dawn-dusk sun-synchronous orbit at about 650 km, with two prototypes due with Planet by early 2027.

The argument for it is simple. In the right orbit, Google says, a solar panel gets up to 8 times more energy per year than one at mid-latitude on Earth, with no land, water or grid connection needed. That part is true. What follows is everything else that has to be true for it to matter.

To its credit, the Suncatcher paper is candid. It calls itself a moonshot, says it is not a full economic feasibility study, and lists thermal management, ground bandwidth and on-orbit reliability as unsolved. This piece takes those caveats seriously and runs the numbers.

Blocker 1: Space is a thermos, not a fridge

Cooling is the hardest problem, and it gets worse with scale. Space is cold, but a vacuum has nothing to carry heat away. No air, no water, no convection. The only exit is infrared radiation, governed by the Stefan–Boltzmann law:

Run the numbers for a radiator at chip-friendly temperatures and it is sobering. Starcloud's own white paper, as cited by the World Economic Forum, puts a two-sided radiator at about 20 °C at roughly 633 W per square metre. A single 1 MW orbital data centre therefore needs about 1,600 m² of radiator. Scaling that same figure, a 1 GW facility needs about 1.6 km², and SpaceX's claimed 100 GW implies something like 160 km² of radiating surface, all of it pointed away from the Sun and the Earth.

Those last two numbers are my own order-of-magnitude scale-ups from one published figure. They ignore hotter radiators, infrared from the Earth below, sunlight and real view factors, any of which could move the answer by a factor of two or three. None of them moves it by the factor of a hundred the gigawatt pitch would need.

The flown reference point is the ISS, and NASA's ATCS overview gives the hard numbers. Its external active thermal control system rejects a maximum of 70 kW through six deployable radiators, each 23.3 m × 3.4 m and weighing 1,123 kg. That is about 6.7 tonnes of radiator panel alone, before pumps, ammonia, rotary joints and plumbing, or roughly 96 kg per kW.

Scale that ratio to 1 MW and the radiators weigh about 96 tonnes. One megawatt of compute, by contrast, is about 98 NVIDIA DGX H100 servers at 10.2 kW and 130 kg each, or roughly 13 tonnes. With ISS-style hardware, the cooling outweighs the computers seven to one.

In fairness, the ISS radiators are designed to run cold. NASA holds the ammonia supply at about 2.8 °C, with a radiator outlet goal of −40 °F, which suits crew modules but is close to the worst case for radiative efficiency. Hotter chips are the strongest counterargument, covered below.

The obvious escape is to run hotter, since radiated power rises with the fourth power of temperature. Silicon disagrees. Leakage current and error rates climb steeply with temperature, and gaining the hundreds of degrees that would really shrink radiators is not plausible for GPUs. You also cannot simply use the back of the solar array: panels want to face the Sun, radiators want to face deep space, and heat has to be conducted from dense chips out to the radiator's edges, which adds more mass.

There is a 90-minute thermal cycle on top. A satellite in most low orbits passes in and out of Earth's shadow every orbit, around 16 times a day, and the repeated expansion and contraction fatigues solder joints and packages. Google's dawn-dusk orbit avoids most eclipses, which is exactly why every serious proposal crowds into that one band. We return to that below.

Blocker 2: Radiation turns memory into a liability

The compute die survives radiation better than expected. The memory does not, and AI workloads are memory-bound. Google's Suncatcher paper gives the first published radiation results for a high-end ML accelerator, and they deserve to be read in full rather than as a headline.

The headline is good: Trillium (v6e) TPUs ran end-to-end ML workloads up to 15 krad(Si) with no hard failures, against an expected 5-year dose of about 750 rad(Si) behind 10 mm of aluminium. The detail is less comfortable:

• HBM fails first. High Bandwidth Memory showed irregularities from 2 krad(Si), under 3× the mission requirement. That is a thin margin for the component every large model depends on.
• Bit flips are routine. HBM produced uncorrectable ECC errors roughly once per 44 rad in the beam. Google judges this acceptable for inference, about one failure per 10 million inferences, but says the effect on training needs further study.
• Some corruption is silent. The team saw data mismatches with no error flag, suggesting silent data corruption at roughly one event per 107 rad in one run. Silent corruption in a training run is the worst kind of bug: the model is quietly wrong.
• The host crashes too. The AMD host server logged functional interrupts, meaning crashes, about once per 450 rad for the CPU and 400 rad for RAM.

The paper also notes that radiation sensitivity, which historically fell as process nodes shrank, stops improving beyond 5 nm. Shielding helps, but shielding is mass, and mass is the one thing a launch-cost model cannot afford. So you pay for this twice: once in aluminium and again in redundancy and checkpointing overhead.

Blocker 3: No hands, no swaps, no refresh

A terrestrial data centre stays up because people walk the aisles. An orbital one must be overbuilt from day one, and it can never be upgraded. The best public data on large-cluster reliability comes from Meta's Llama 3 paper. Over a 54-day snapshot on 16,384 H100s, the job saw 419 unexpected interruptions, roughly one every three hours. About 78% were confirmed or suspected hardware faults, and GPU issues alone made up 58.7%.

It is important to read that number correctly. Those are job interruptions, not dead cards, and Meta's automation handled almost all of them. That cuts both ways for orbit. Restarts and remapping work in space too, but Meta still needed significant manual intervention three times in 54 days, and in orbit there is nobody to do it.

Google's paper is honest about this. Failed TPUs are swapped by technicians on Earth, which it calls impracticable in space, and its fallback is redundant provisioning. Every spare chip is extra mass, extra radiator and extra solar array.

Then there is obsolescence, and here the honest comparison is closer than it first looks. Hyperscalers depreciate servers over five to six years, and Amazon cut a subset from six years to five in 2025, citing the increased pace of AI and ML development. That is close to the five-year satellite life Google's cost model assumes.

The difference is what gets thrown away. On the ground, you rack the new generation into the same building, on the same power feed and cooling plant, which last for decades. In orbit the whole satellite is the server. When the chips are stale, the solar panels, radiators and structure burn up with them, and all of it has to be launched again.

Blocker 4: The pipe to the ground is a straw

The link between orbit and Earth is the narrowest point in the system, and the clouds get a vote. The current record for a space-to-ground laser link is NASA and MIT Lincoln Laboratory's TBIRD, which hit 200 Gbps in April 2023. That is a superb engineering result. For scale, a single NVIDIA DGX H100 server has eight GPU-fabric ports at up to 400 Gbps each, 3.2 Tbps in total. The best laser downlink ever demonstrated is a sixteenth of one server's network.

The constraints behind that number matter more than the number itself:

• Passes, not connections. A LEO satellite only sees a ground station for a few minutes per pass. TBIRD worked in roughly 5-minute windows. Anything continuous has to hop across inter-satellite links to whichever satellite is overhead.
• Weather. Optical links are scattered by cloud and distorted by turbulence. TBIRD's ground station sits on Table Mountain, chosen because most weather happens below the summit. Your users do not live on mountaintops, so you need many geographically diverse stations to dodge cloud.
• Radio is slower still. Google's paper says its pilot will use radio for the ground link, because optical ground links remain an unsolved challenge for scaled operation.

Inside the cluster, the gap is just as stark. Google's TPUs talk to each other at hundreds of Gbps per chip. Commercial optical inter-satellite links manage 1–100 Gbps. Suncatcher closes that gap only by flying satellites 100–200 m apart, which is its own problem (see Blocker 6).

Raw latency is not the issue: 650 km is a few milliseconds. The issue is that the paper itself admits the dawn-dusk orbit increases latency to some ground locations. For training a model, that hardly matters. For serving a web app to a user, when the cluster is on the far side of the terminator, every request takes extra relay hops through someone else's network.

Blocker 5: The economics only close on a forecast

At today's launch prices, orbital power costs 5–25 times what a terrestrial data centre pays for electricity. Parity depends on launch costs falling about 18-fold, and even then the comparison leaves out most of the bill. Google's own launch cost analysis is the most careful public attempt, so here are its figures, amortised over a five-year satellite life:

Three caveats sit inside that table, all from the paper itself:

1. The $200/kg is a forecast. It extrapolates a 20% learning rate from Falcon 1 to Falcon Heavy, and needs about 180 Starship launches a year, sustained, to arrive around 2035.
2. It compares launch with electricity, nothing else. Buildings, cooling plant, ground stations and chips are excluded. Google calls it a high-level, indicative comparison, not a feasibility study.
3. The mass ratio is borrowed from Starlink. A communications satellite's kg per kW is not a data centre's. Radiators sized for chip-temperature heat loads (Blocker 1), shielding (Blocker 2) and spare capacity (Blocker 3) all push mass per kW upwards.

The ground side is not standing still either. Terrestrial solar keeps falling in cost, and a building on Earth gets 20+ years of use from its power and cooling while the chips inside it are swapped. An orbital facility re-launches the whole power plant every five years. Even if the space side wins on the kWh, it loses on the asset lifecycle.

Blocker 6: The orbits are a shared commons, and they're filling

The orbits these designs need are the ones already closest to a debris cascade. Scaling compute into them multiplies a risk that falls on everyone who uses space, not only on the operator. ESA's Space Environment Report 2025 gives the baseline. About 40,000 objects are tracked, of which about 11,000 are active payloads. More than 1.2 million fragments larger than 1 cm, each big enough to destroy a satellite, are estimated to be in orbit.

Two findings from that report matter most here:

• Debris already matches satellites. Around 550 km, the number of threatening debris objects is the same order of magnitude as the number of active satellites.
• The cascade has started. Even with no further launches, debris would keep growing, because fragmentation adds objects faster than the atmosphere removes them. ESA concludes that active removal is now required.

Now add the proposals. SpaceX's application, accepted for filing by the FCC in February 2026, asks for up to a million satellites in shells up to 50 km thick between 500 and 2,000 km, including sun-synchronous orbits. It also asks for waivers of the usual deployment milestones and surety bond.

The Secure World Foundation's comments to the FCC put that in context. There were slightly under 15,000 active satellites in low orbit when they wrote, so this one application is roughly 67 times the entire current fleet. Even a 99% disposal success rate, they point out, would leave up to 10,000 dead satellites in orbit at full scale. Higher up, atmospheric drag is weak, so anything that dies or fragments there can stay for decades or longer.

The physics of power makes it worse. Continuous sunlight comes from the dawn-dusk sun-synchronous band, so every operator wants the same narrow ring. Google's design flies 81 satellites in a 1 km cluster with neighbours 100–200 m apart. That is close formation flying at scale, in the low orbits ESA already describes as getting crowded. One collision inside a cluster like that does not create a single debris cloud. It creates one that is already sitting among 80 neighbours.

The operator's cost is not the real cost here. A data centre fire on Earth damages one building. A cascade in low orbit damages navigation, weather forecasting, Earth observation and communications for everyone, for generations.

Blocker 7: The mass has to go somewhere

Every satellite eventually stops working, and an orbital data centre is a deliberate plan to retire millions of tonnes of hardware on a five-year cycle. There are only three places that mass can go, and each one is a problem.

Burning it up is already measurable. This is not a modelled risk. NOAA flew a laser mass spectrometer through the stratosphere and found aluminium and exotic metals from spacecraft re-entry in about 10% of stratospheric sulphuric acid particles larger than 120 nm. The giveaway was niobium and hafnium, which come from aerospace alloys, not meteors. Re-entry already puts more lithium, aluminium, copper and lead into the stratosphere than cosmic dust does. NOAA estimates that planned constellations could push the share of contaminated particles to half.

Aluminium oxide is a catalyst, not a reagent. A USC study in Geophysical Research Letters modelled how a satellite's aluminium oxidises on the way down. A typical 250 kg satellite produces about 30 kg of aluminium oxide nanoparticles. These don't react with ozone themselves. They speed up the reactions between ozone and chlorine and survive to do it again, for decades. The particles can take up to 30 years to sink into the ozone layer, so the damage from today's re-entries lands in the 2050s.

Nobody knows what it does to the climate yet, and that is the point. A 2025 NOAA/CIRES study modelled 10,000 tonnes of alumina a year, roughly what 60,000 satellites on five-year lives would produce by 2040. It found up to 1.5 °C of warming near the poles and a 10% slowdown in the Southern Hemisphere polar vortex. Counterintuitively, that could weaken the Antarctic ozone hole. But the model treated the particles as chemically inert, so it left out exactly the surface chemistry the USC study worries about. The honest summary is that the effects are real and even their direction is unknown. Scaling this up is an unplanned geoengineering experiment on the ozone layer.

Launches add a second hit. A 2025 npj Climate and Atmospheric Science study found that 2,040 launches a year would thin global ozone by 0.29% and Antarctic springtime ozone by 3.9%, mostly through black carbon. Even its conservative case of 884 launches a year, which current licensing may exceed before 2030, gives 0.17%. The ozone layer is still about 2% below its pre-CFC level.

The scale is off every chart anyone has drawn. SpaceX frames its system as 1 million tonnes of satellites. On Google's five-year life assumption, that is 200,000 tonnes of hardware to retire every year. If it all re-entered at the USC study's ratio of 30 kg of oxide per 250 kg of satellite, that is roughly 24,000 tonnes of aluminium oxide a year. That figure is my extrapolation, not a published one, but it is more than twice the largest scenario NOAA has modelled and about 65 times the USC projection for every constellation planned in 2024.

Parking it instead just moves the problem. SpaceX doesn't plan to burn everything up. Its filing describes a mix of re-entry, high-altitude disposal orbits and heliocentric orbits around the Sun. The Secure World Foundation warns that long-lived disposal orbits create persistent debris in regions that are currently clean, that nobody can fix a failed heliocentric disposal at this scale, and that the atmospheric effects of mass re-entry are not yet understood.

A building on Earth has none of these end-of-life problems. When the servers are obsolete, they go to a recycler and the shell gets the next generation.

Blocker 8: "In orbit" is not a jurisdiction

An orbital data centre does not escape national law. It belongs entirely to whichever state registers it, and for a European customer that is usually not their own. Under the 1967 Outer Space Treaty, as summarised by UNOOSA:

• Article VI: a state bears international responsibility for national activities in space, and private operators need authorisation and continuing supervision by the appropriate state.
• Article VIII: the state of registry retains jurisdiction and control over the object. In practice, the operator's home state is expected to register it.

So a SpaceX orbital data centre is, legally, a US facility that happens to move at 7.5 km/s. A UK or EU organisation that moves workloads there has not achieved neutrality. It has moved its data under a foreign legal system, with every request also crossing ground stations in whatever countries the cluster happens to be passing over.

This is the opposite of what data sovereignty asks for. A rack in Dublin or Frankfurt sits under one clear legal regime you can audit. A satellite sits under another country's regime and passes over dozens more every orbit, which makes residency and compliance messier for exactly the enterprise customers a cloud depends on.

There is a harder edge too. Large compute clusters are strategic assets. An orbital one is a fixed, predictable, unhardened target with no perimeter fence, in a domain where an anti-satellite missile test at the end of 2021 left a debris cloud ESA was still tracking years later.

The best case for it, and why it still falls short

The strongest arguments for orbital compute are real, and they deserve a straight answer rather than a sneer.

"Just run the chips hotter." Radiated power rises with the fourth power of temperature, so a radiator at 80 °C sheds about twice what one at 20 °C does. Elon Musk has argued that raising chip temperature by 20% in kelvin halves radiator mass. That is genuine physics and it helps. But leakage and error rates climb with temperature, HBM is already the weakest link under radiation (Blocker 2), and a twofold gain against radiators that can outweigh the compute several times over narrows the gap rather than closing it.

"Starlink already proves the operations model." It largely does. Even the Secure World Foundation credits SpaceX with conservative manoeuvre thresholds and strong disposal performance. The problem is that per-satellite excellence does not scale to the aggregate. A 1-in-1,000 risk that is fine for one spacecraft is not fine multiplied by a million.

"Inference isn't training." This is the best argument. Google judges its radiation error rate acceptable for inference, at about one failure per 10 million inferences, and inference needs far less tight coupling between chips than training does. But inference is exactly the workload that serves users on the ground, so it runs straight into the downlink and latency limits of Blocker 4.

"Launch will keep getting cheaper." Probably true. Even at Google's projected $200/kg, though, parity is with the electricity bill alone, not with the full lifecycle (Blocker 5).

"The ground is running out of room." Grid queues, water and local opposition are real constraints, and the WEF cites polling that 70% of Americans oppose a data centre near them. Those are planning, policy and generation problems, though, and they have terrestrial answers, such as building next to new generation. The problems in orbit are physics.

Each answer narrows one gap. None of them removes the need for all the others.

What works: compute next to data that's already up there

Orbital compute makes sense when the data starts in orbit and the downlink is the bottleneck. That is a real, valuable niche, and it is the opposite of a general-purpose cloud. The clearest evidence is a hyperspectral imager on the ISS whose data goes home on storage drives on cargo ships, because the station cannot downlink it fast enough.

For that kind of workload, every blocker above shrinks or flips:

• Heat is a few hundred watts per satellite, not megawatts.
• Radiation errors are tolerable when the job is filtering imagery, not training a frontier model.
• Bandwidth improves, because you send down answers (a ship detected here, a fire there) instead of raw pixels.
• Lifecycle matches, because the processor lives and dies with the sensor it serves.

That is where the early hardware is going. Starcloud has already flown a satellite carrying an NVIDIA H100, and Google's first Suncatcher prototypes are a joint mission with Planet, an Earth-imaging company. Both are good engineering, and both make the most sense as edge compute.

The gigawatt AWS-in-orbit story is a different thing. It needs radiators measured in square kilometres, memory that shrugs off radiation, and a commons that can absorb a sixty-sevenfold increase in active satellites. It also needs a launch-cost curve to keep going for another decade. Some of those may improve. All of them have to, at once, and the ground keeps getting cheaper while you wait.

The engineering lesson is an old one: pick the right tech for the right system. Put compute where the data and the users are. For satellite imagery, that is sometimes in orbit. For the web, it is a well-run building with cheap power, good fibre and a technician who can swap a failed card on a Tuesday afternoon. That is boring technology, and boring works.