The Data Centers in LEO
Part I — WHY ORBIT, WHY NOW

The inversion

Now put the two halves together, because the argument of this book is a single comparison.

Figure 3.1 — The inversion

On Earth, energy is scarce in the sense that matters, scarce in time, rationed by a queue, while getting rid of heat is a solved commodity problem. You buy a chiller. You dig a cooling loop. Worst case, you evaporate water. In low Earth orbit, both halves flip. Sunlight arrives at about 1,361 watts per square metre, unfiltered by atmosphere, on nobody’s schedule and with nobody’s permission. In the right orbit a spacecraft sees it almost continuously. Nothing in that sentence involves a transformer lead time. And heat becomes the hardest problem you have. Not because there is a lot of it, there is exactly as much as on Earth, because the physics of Chapter 1’s primer does not care where the rack is but because in a vacuum there is no air to blow over a fin and no water to boil off. There is one and only one exit: infrared radiation into the dark sky. Radiators are the entire cooling system, they are large, and they set the mass and the deployment complexity of the spacecraft. Chapter 5 does this arithmetic honestly, and it is the chapter I would most like a sceptic to attack. Radiation, meanwhile, goes from not a consideration to a permanent design constraint, and bandwidth goes from free to a budget you must engineer. These four, power, heat, radiation, bandwidth are the spine of the book. Every sector in Part IV is a company attacking one of them. So it should be said plainly, at the start, that going to orbit does not remove constraints. It substitutes them. You trade a scheduling problem for a physics problem: an interconnection queue for a radiator area, a transformer order book for a launch manifest. That trade is only a good one if the physics problem is smaller than the scheduling problem, and whether it is depends on numbers we will build up over the next hundred pages.

The argument that survives even if orbit is expensive

There is a weak version of the orbital case and a strong one, and most writing on this subject makes the weak one. The weak version is a cost argument: orbital compute will be cheaper per GPU-hour than terrestrial compute. Over a two-year view this is difficult to defend, because it leans on a Starship price nobody has yet paid and on hardware lifetimes nobody has yet demonstrated. The strong version is an availability argument, and it is already true.

Even at the bottom of that range, the conclusion holds and it is the most important sentence in Part I: An orbital data centre does not have to be cheaper than a terrestrial one. It has to exist sooner.

Two warnings about that sentence, both discharged in Part V. The first is that “the alternative” is not only a grid connection, it is a gas turbine on site, and Chapter 18 prices that competitor properly. The second is that orbit is not instant either: from decision to first operating megawatt is three to four and a half years. The availability argument survives both, in a narrower and more precise form than this page implies: orbit wins today for buyers who pay a premium for sovereignty, resilience or proximity to a sensor, and it wins for everyone else once manufacturing has come down its learning curve, which Chapter 18 dates to the early 2030s. That is a much weaker claim than the one usually made for this sector, and weaker claims are the ones that survive contact with engineering. It is also why the rest of this book spends its time on radiators, radiation dose and optical links rather than on renderings. If the availability argument is the real one, then the question is not whether orbital compute is desirable. It is whether it is buildable, part by part, at the scale the argument requires. That question has nine answers, one per subsystem, and they are what Part II and Part III are for.


Download as PDF