Essay · June 15, 2026 · 10 min read

Space Compute Is Not a No-Brainer

SpaceComputeEconomics
Space Compute Is Not a No-Brainer

This is an independent analysis based on public sources and a simple economic model. It is not investment advice.

The best version of the space-compute argument is not silly.

AI data centers are running into real bottlenecks on Earth: interconnection queues, turbines, transformers, land, permits, water, local resistance, and the slow institutional machinery around large infrastructure. Put compute in orbit and one part of the story changes. In a well-chosen sun-synchronous orbit, solar panels can see near-continuous sunlight. Google’s Project Suncatcher starts from the same intuition: space-based solar can be materially more productive per unit area than terrestrial solar, and a satellite constellation avoids some terrestrial constraints.

That is the pitch.

The catch is that orbital compute does not make constraints disappear. It moves them.

It trades a terrestrial power bottleneck for an orbital heat-rejection bottleneck. It trades land and permitting for launch mass, radiation, maintenance, replacement cycles, and high-bandwidth space networking. The first set of problems is mostly institutional and supply-chain driven. The second set is much closer to physics.

That difference matters. Institutions adapt. Physics does not care about the IPO story.

The Three-Port Machine

Strip away the science-fiction layer and a data center is a three-port machine. It takes in energy, rejects heat, and emits information.

On Earth, the energy input is getting harder. Heat output is still comparatively forgiving. Air, water, cooling towers, liquid loops, and the local environment form a huge heat sink. Network output is also cheap because fiber already exists.

In orbit, the energy story looks attractive. Solar is abundant and continuous in the right orbit. It is not constrained by a local utility queue. But heat output becomes the problem. Space is cold, but it is also a vacuum. There is no air to convect heat away and no local water system to dump heat into. The remaining path is radiation.

Framework: from power bottleneck to heat bottleneck
Framework: from power bottleneck to heat bottleneck

So an orbital data center is not simply “a data center, but in space.” It is a different physical object.

Port Terrestrial Data Center Orbital Data Center
Energy input Constrained by grid, permits, turbines, transformers Improved by continuous solar access
Heat output Helped by air, water, cooling towers, liquid cooling Constrained by radiation-only heat rejection
Information output Helped by fiber and metro networks Constrained by lasers, ground stations, latency

The question is not just whether it can work. The question is which constraint is cheaper to carry for long enough.

Cooling Is the Dominant Constraint

The most common bad intuition is that space is cold, so cooling should be easy.

Vacuum is not a cooling system. In vacuum, heat mainly leaves through radiation. Radiative heat rejection follows the Stefan-Boltzmann law: power rises with the fourth power of absolute temperature. Higher radiator temperature helps a lot, but chips, packaging, fluids, pumps, and structural materials impose ceilings. If temperature cannot rise enough, radiator area has to grow.

NASA’s public material on the International Space Station’s External Active Thermal Control System says the system rejects about 70 kW of heat across two ammonia loops. Tom’s Hardware reported that SpaceX’s first-generation AI1 orbital compute satellite is designed around an average compute payload of about 120 kW and a peak of about 150 kW, with up to 110 square meters of deployable liquid radiators.

Those numbers do not prove AI1 is impossible. They do show why this should not be described as “Starlink thermal design, scaled up.” A high-power AI rack in vacuum is a hard thermal-management problem. Every answer comes back as area, mass, complexity, reliability risk, or cost.

That is also why launch cost can dominate the conversation too easily. Dollars per kilogram is visible. Thermal mass is less visible. But radiators, loops, pumps, shielding, attitude constraints, and redundancy all turn back into kilograms and replacement cycles.

Radiation, Bandwidth, and Serviceability Keep Training on Earth

Radiation is the second hard constraint. The third sounds less glamorous, but may matter just as much: what happens when hardware breaks?

Google’s Project Suncatcher is useful because it published real tests rather than just a slogan. Google tested Trillium, its v6e TPU, in a proton beam. The result was cautiously positive: high-bandwidth memory was the sensitive subsystem, with irregularities beginning around 2 krad(Si), while the chip did not show hard failures attributable to total ionizing dose up to 15 krad(Si) in that test.

That is good news for orbital inference. It is not a clean green light for frontier-model training.

Inference can be made fault tolerant. You can replicate, retry, reroute, degrade gracefully, and move workloads away from unhealthy nodes. Training is different. Large-scale training needs tight synchronization, huge bandwidth, low latency, and high cluster reliability. Inter-satellite optical links are impressive. They are not NVLink inside a rack, and they are not a terrestrial training fabric.

There is also a more mundane point. Terrestrial AI clusters are not low-failure machines. They are machines that keep running because failures are found, isolated, repaired, and restarted around. In the Llama 3 405B technical report, Meta disclosed that a 16K GPU training run saw 466 job interruptions in one 54-day window, including 419 unexpected interruptions. Roughly 78% of the unexpected interruptions were tied to confirmed or suspected hardware issues: GPUs, HBM3, switches, cables, NICs, and silent data corruption among them. Meta still kept effective training time above 90%. That is not because nothing failed. It is because the system was built to survive failure.

That operating model works on Earth because a bad accelerator can be pulled, a cable can be replaced, a server can be serviced, and spare parts can arrive quickly. In orbit, a failed GPU is not a board a data-center technician can swap. It is dead mass inside a spacecraft. Unless the compute payload is designed for orbital module replacement from day one, failures in GPUs, HBM, pumps, valves, connectors, or power modules become lifetime loss or redundancy burn.

Orbital replacement is not free either. It needs standardized servicing interfaces, robotic or crewed servicing vehicles, rendezvous and docking, spare modules, blind-mate electrical and thermal connectors, extra structure, test procedures, and new failure modes. Hubble is one of the rare spacecraft intentionally designed for astronaut servicing, and even that required Space Shuttle missions, astronaut training, and deep ground coordination. NASA’s OSAM-1 robotic servicing mission was later cancelled after technical, cost, and schedule challenges. The lesson is not that servicing is impossible. It is that it is nowhere near as routine as swapping a card in a data center.

Serviceability comparison: ground replacement versus orbital repair
Serviceability comparison: ground replacement versus orbital repair

This is why the near-term orbital-compute opportunity is probably narrower than the headline:

  1. Inference workloads that can tolerate some latency and some failure.
  2. Processing space-native data in orbit before downlinking results.
  3. Sovereign, defense, or resilience workloads where cost is not the only variable.

Those are real markets. They are not the same thing as replacing terrestrial AI factories.

The Economics Are Not Just Launch Cost

Economics: launch-cost thresholds for orbital compute
Economics: launch-cost thresholds for orbital compute

The optimistic model tends to compress everything into launch cost. If Starship gets cheap enough, the data center goes to space.

That is only half right.

The real model has at least four variables:

  1. Launch price: dollars per kilogram.
  2. Platform mass: kilograms of satellite platform, solar array, radiator, structure, and communications per kilowatt of compute.
  3. Platform cost: dollars per watt for space-grade power, thermal, communications, and control systems.
  4. Lifetime loss: degradation, radiation effects, pump failures, chip failures, redundancy, and replacement cadence.

That fourth line should be split one layer further: serviceability. In a terrestrial data center, a bad card is not automatically a write-off. The machine detects it, isolates it, replaces it, recovers capacity, and moves on. If an orbital data center cannot support card-level or node-level replacement, hardware failure rates translate directly into higher redundancy, shorter depreciation schedules, and higher effective compute cost. Serviceability is the hidden fifth variable.

Silicon Valley 101’s Episode 239 is useful because it walks the model back from fantasy to engineering. Counting only propellant energy, the payback can look like two months. At around $200/kg, it becomes closer to a thin two-year breakeven. Add GPU degradation and other losses, and the hosts discuss roughly 40% extra redundancy. The more comfortable threshold in that discussion moves toward roughly $10-20/kg.

Google’s Suncatcher analysis is more cautious. It argues that, if launch prices fall below $200/kg by the mid-2030s, the cost of launching and operating space-based compute could become comparable to reported terrestrial energy costs on a per-kilowatt-year basis.

That is an important statement, but it is not the same as saying orbital compute beats the all-in cost of a terrestrial data center. Terrestrial data centers are not just energy costs. Orbital data centers are not just launch costs.

The thesis only works if several things happen together: launch costs fall sharply, space-platform cost per watt falls sharply, thermal mass is manageable, chip lifetimes are long enough, and terrestrial power scarcity remains expensive for long enough. This is not a one-variable bet.

Once serviceability is added, the bar rises again. The question is not merely how long a satellite can operate. It is what happens when part of its accelerator, memory, networking, or thermal-control stack starts failing. Can the system degrade and recover the way a terrestrial cluster can? That is the boundary between a demonstration system and infrastructure.

The best argument for the bulls is Starlink. Many people doubted low-Earth-orbit broadband economics. SpaceX then used vertical integration, launch reuse, and satellite mass production to change the cost curve.

That precedent deserves respect. It also has limits.

Starlink works because it serves demand that terrestrial networks struggle to reach: rural homes, ships, aircraft, remote industrial sites, defense users, disaster zones. It is not merely a cheaper substitute for urban fiber. It serves places where the ground solution is unavailable or structurally poor.

Orbital compute faces a different competitive set. Its rival is not “no compute.” Its rival is terrestrial data-center capacity that is still expanding, optimizing, and searching for new power structures: behind-the-meter gas, nuclear restarts, large battery systems, brownfield industrial sites, Canadian hydro, Nordic cooling, Middle Eastern power, and Chinese western power bases.

That makes orbital compute look less like Starlink and more like Iridium. Iridium was technically remarkable. Its problem was that terrestrial cellular networks improved faster than the satellite business could amortize its cost structure.

For orbital compute to win as a general-purpose substitute, Earth has to stay constrained for long enough. That is a time-window bet, not a law of nature.

What I Would Actually Underwrite

I would not underwrite “space data centers replace terrestrial AI factories” as the base case.

I would underwrite the narrower version:

  1. Space-native edge compute becomes real. Earth observation, SAR, weather, defense, and space-domain-awareness workloads increasingly process data in orbit and downlink results rather than raw data.
  2. Some inference workloads move to orbit where power scarcity, sovereignty, or resilience matters more than all-in cost.
  3. The real venture opportunity is upstream: space-grade solar arrays, deployable radiators, thermal pumps, phase-change materials, radiation-tolerant high-bandwidth communications, optical inter-satellite links, and software for orbital workload orchestration.

This version is less dramatic. It also has a higher base rate.

Starcloud’s public materials, for example, frame space data centers around continuous solar, radiative cooling, and avoiding terrestrial permitting constraints. Y Combinator’s page says the company has flown an Nvidia H100 in orbit and used it for AI workloads. That is a credible early signal for space-native compute. It is not proof that a gigawatt-scale orbital AI factory is cheaper than Earth.

Conclusion

Space compute is not a scam. There is a real first-principles improvement in the idea: convert solar energy into bits in orbit, then downlink information. Sending information is much more sensible than sending energy.

But that does not make orbital compute a general replacement for terrestrial data centers.

As a space-native edge-compute market, it is real. As a defense and sovereignty market, it is plausible. As an upstream component opportunity, it is worth tracking. As a claim that the cheapest AI compute will soon be in orbit, it still carries too many unproven assumptions.

The missing proof is not just compute. It is maintainable compute. A terrestrial AI factory is not a pile of GPUs that never fail. It is an operating system for detecting failures, isolating failures, replacing failures, and resuming work. Unless orbital compute can build an equivalent serviceability model, its effective lifetime and unit economics will keep eroding.

The cleanest formulation is still this: putting compute in space is hard, but not the hardest part. Putting it there economically is the hard part.

Elon Musk has turned a constraint swap into a constraint-elimination story. That is good storytelling, and it may push real engineering forward. But physics does not underwrite IPO narratives for free.

Sources