Skip to content

CONCEPT Cited by 1 source

Space-based compute

Space-based compute is the architectural choice to deploy the compute substrate in orbit rather than terrestrially. Drivers:

  1. Continuous solar power. In the right orbit, a solar panel is "up to 8 times more productive than on earth, and produce power nearly continuously, reducing the need for batteries" (sources/2025-11-04-google-exploring-space-based-scalable-ai-infrastructure). Higher instantaneous yield + near-continuous generation changes both perf/watt and the energy-storage sizing constraint simultaneously.
  2. Unbounded energy-supply ceiling. "The Sun is the ultimate energy source in our solar system, emitting more power than 100 trillion times humanity's total electricity production." The energy-supply side of the scaling problem is essentially unbounded if compute can physically reach it.
  3. Terrestrial resource minimisation. Land, grid capacity, water for cooling, and construction materials are all first-class design constraints. The Google Research 2025-11-04 announcement frames minimisation of these terrestrial resources as a first-class design driver, alongside scale: "this approach would have tremendous potential for scale, and also minimizes impact on terrestrial resources."

Relationship to AI-scale economics

The argument shape is: as AI-serving demand scales, the bottleneck shifts from compute economics (Moore-curve) to grid-capacity economics and siting economics (water, land, permitting). Space-based compute reframes the scaling problem as a physics + manufacturing problem — launch cadence, satellite manufacturing throughput, inter-satellite link bandwidth — rather than a grid-and-permit problem.

This is sibling to the dual economics/sustainability framing the same Google Research org uses for terrestrial-cluster efficiency work (see [[sources/2025-10-17-google-solving-virtual-machine-puzzles-lava|2025-10-17 LAVA]]: "at the scale of large data centers, efficient resource use is especially critical for both economic and environmental reasons"). The 2025-11-04 post and the 2025-10-17 post are arguing from the same motivator at two very different layers — squeeze the terrestrial cluster harder vs. move the cluster off-planet.

Challenges

Space-based compute inherits a cluster of hard sub-problems not present in terrestrial deployment. The 2025-11-04 Suncatcher announcement names three as foundational-research challenges for its constellation shape:

  1. High-bandwidth inter-node communication. Terrestrial datacenters assume cheap fibre; orbital constellations must solve inter-satellite networking at AI-workload bandwidths. The Google-chosen substrate is free-space optical links.
  2. Orbital dynamics. Formation flying at the compactness needed to keep FSO link budgets manageable is a harder geometry problem than widely- dispersed LEO constellations.
  3. Radiation effects on computing. Commodity silicon (in Google's case, TPUs) was not designed for the orbital radiation environment. Mitigation is pushed into architectural / software layers rather than radiation-hardened silicon, to preserve access to the commercial process-node curve.

Additional challenges the 2025-11-04 post does not enumerate but that apply generally: thermal management in vacuum, space-to-ground downlink (FSO through atmosphere incurs weather penalties), launch cost / cadence, serviceability / upgradeability, and end-of-life de-orbit.

Architectural shape

The Google-chosen shape is modular disaggregated constellation — "compact constellations of… smaller, interconnected satellites" rather than one monolithic orbital platform. Capacity scales by adding satellites; failures degrade the constellation rather than the platform; the unit of replacement / upgrade is small and frequent. At the space layer, analogous to the commodity- cluster-vs-supercomputer shape shift that drove terrestrial distributed systems.

Seen in

Last updated · 200 distilled / 1,178 read