The Demand Side Showed Up
Google and SpaceX are reportedly talking about data centers in orbit. That changes the question the software has to answer.
On Tuesday the Wall Street Journal reported that Google and SpaceX are in talks about putting data centers in orbit. Nobody has confirmed anything. The IPO is the obvious backdrop and the story may go nowhere. We are writing about it anyway, because it marks a shift that has been building for months and this is the clearest sign of it so far.
Until now, orbital compute has been a supply-side story. Someone builds a satellite with a GPU in it, gets it to orbit, and then goes looking for something to run on it. Starcloud did it with an H100. Axiom did it with nodes on the station. Cowboy Space, which was Aetherflux until recently, just raised a large round to build a one-megawatt compute unit. Every one of these is a bet that if you put the hardware up, the workloads will follow.
A hyperscaler in the conversation is a different kind of participant. Google does not buy chips. Google buys capacity, and capacity comes with a set of questions that none of the supply-side announcements have had to answer yet.
What a capacity buyer asks
If you have ever been on the receiving end of a cloud capacity negotiation, you know the shape of the questions. How much can I count on. When. With what availability. What happens when something fails, and how do I know.
Translate those to orbit and every one of them becomes a question about time.
How much can I count on is not a number. It is a function of the orbit, because a satellite’s power budget follows the sun and a third of every orbit is spent in the Earth’s shadow. When is not a calendar slot, because the satellite is only over a given ground station for a few minutes at a time, several times a day. Availability is not a percentage you negotiate. It is something you compute from the orbital elements, and it changes as the orbit precesses.
None of this is a problem for a single demonstration satellite. You schedule around it by hand. It becomes a problem the moment a buyer wants a fleet, and a buyer like Google only wants fleets.
Three stages of demand. Each one asks the software a harder question than the last.
Where that leaves the software
We have spent the last year building the second column. You give the planner a satellite and a workload. It propagates the orbit, finds the eclipse and the ground passes, places each step of the workload on board or on the ground, and lays the whole thing on a timeline that respects power and contact windows. If the workload cannot fit, it says so and names the constraint. That is the CAE API, and it runs every time someone calls it.
The third column is the same problem with more satellites in it, and it is where our attention has been going. The constellation endpoint takes the same workload and asks which satellites in a set can run it, and when. Under the hood that is still feasibility, still windows, still a timeline. The difference is that the answer is now a schedule across a fleet rather than a plan for one node, and a buyer can read it as capacity.
We are not going to pretend that is finished. A hyperscaler contract would come with requirements we have not seen yet, and we would be naive to guess at them. But the shape of the question is now clear, and it is the shape we have been designing for.
The quiet part
There is a version of this story where the talks are a negotiating tactic ahead of a listing and nothing comes of them. That version is entirely possible.
There is another version where the first hyperscaler-scale orbital compute contract gets signed sometime in the next two years, and whoever holds it discovers on day one that the hard part was never the chips. The hard part is answering the capacity question honestly, for a fleet that spends a third of its life in the dark and only talks to the ground for a few minutes at a time.
Either way, the demand side has shown up. The software has to be ready for it.