Orbital compute has stopped being a thought experiment. Starcloud launched the first commercial data centre satellite in late 2025, flying a modified Nvidia H100 running Gemini in space, and the sector had drawn more than US$3 billion by April 2026. The question on your team’s agenda has shifted from “is this real?” to “should I build or buy?”
That is harder than it looks, because almost every vendor number, on cost, cooling and radiation tolerance, rests on modelled launch prices and unproven targets. Committing on faith is a gamble you cannot afford. The aim is a decision posture: when to engage, when to wait, what evidence to demand, and where each choice sits in the wider orbital data centre landscape.
Build versus buy for orbital compute capacity: what’s the calculus?
For most teams the calculus resolves to buy or pilot, not build. Constructing an orbital data centre demands capital, launch access and in-space engineering that few organisations hold, so the build path is realistic only for hyperscale or vertically integrated operators. Pay margin at every interface and the margin stack adds up, and heat rejection alone, a mass-and-area problem, is reason to stay on the buying side.
Workload fit and control should drive the decision, ahead of enthusiasm for the technology. Orbital compute suits latency-tolerant work: batch and scheduled inference, analytics on data already in orbit, scientific simulation. Roughly three quarters of AI workloads tolerate 5 to 20 milliseconds of added latency, so much of the market is in play. Latency-critical interactive workloads are the exception; low Earth orbit imposes round-trip delay.
Outside that integrated class, the pragmatic route is to buy capacity from an early provider. It lets you test fit without owning the physics, the launch risk or the thermal management on your balance sheet. Treat it as a portfolio decision: own the workload that differentiates you and buy the surrounding infrastructure, and in orbit, the surrounding infrastructure is the hard part.
When should you engage orbital providers versus wait for cost parity?
That buy-versus-build answer only raises the timing question: when to buy. Engage early only with a genuine fit, sovereignty, latency-tolerant inference or data already in orbit, and only where the premium is tolerable. For everything else, the disciplined default is to wait, watch provider maturity, and keep terrestrial capacity as your baseline.
Cost parity is modelled around 2040, not now. Independent modelling puts space compute at roughly four times terrestrial on levelised cost, about US$10.91 per GPU-hour in orbit against US$2.49 on the ground, driven by launch costs and a five-year asset life against fifteen years on the ground. By the early 2030s the premium could narrow to around 30 per cent.
The decision rule is short. A genuine workload fit plus a tolerable premium means run a pilot; no fit means wait and watch. The decision runs through a sequence of gates. Watch these named milestones rather than waiting for a single announcement: Starcloud-2 in October 2026, Aetherflux‘s first node in early 2027, and Google’s prototype mission with Planet Labs in 2027. Keep a little scepticism while you watch: SpaceX‘s S-1 filing warns its orbital plans “involve significant technical complexity and unproven technologies, and may not achieve commercial viability”. If SpaceX’s own S-1 hedges this heavily, apply the same scepticism to smaller claims.
How do I pressure-test orbital vendor claims and hype before committing to a pilot?
Due diligence here is a scrutiny exercise. Ask for verifiable per-megawatt economics, radiator and power budgets that close against mass and area, radiation-qualification evidence, lifetime, servicing and redundancy assumptions, and named pilot references. If a vendor cannot produce these, you are looking at a slide deck rather than an operation.
Cooling is where the physics catches most vendors out. A vacuum has almost nothing to conduct heat away, so waste heat must be radiated; a single 1-megawatt orbital data centre needs about 1,600 square metres of radiator, roughly a hockey rink. Treat “free cooling”, “free solar” and “no permitting” as red flags, along with round numbers and capacity targets nobody reconciles.
Radiation is the other claim to test against hard evidence (beam tests and flight history) rather than vendor roadmaps. Radiation in low Earth orbit runs 20 to 30 times higher than on the surface, and shielded commercial silicon with architectural hardening beats expensive rad-hard chips, but a ground beam test is not years of cluster-scale operation. Google’s proton-beam results separate engineering from aspiration.
Finally, insist on a cost unit tied to your workload, ideally cost per GPU-hour or per billion tokens, so the orbital figure sits beside your terrestrial benchmark. Treat the pilot as a time-boxed exercise proving throughput, sustained operation under radiation and eclipse, and a cost per unit matching the claim. A provider that resists defining acceptance criteria is itself a finding.
Does a sovereign AI workload genuinely justify the orbital premium?
The hardest claim to scrutinise is the one most buyers want to believe: sovereignty. Sovereign compute is a policy and jurisdictional proposition. The test is whether the orbital premium buys jurisdiction and control you could not already achieve on the ground through private cloud, data residency or behind-the-meter generation. In most cases the answer is no, at least not yet.
The jurisdictional position is unsettled, which is why the claim needs testing. Under Article VI of the 1967 Outer Space Treaty, a satellite stays under the supervision of its launching state, while terrestrial law such as the GDPR still claims the data, an arrangement one commentary calls a “jurisdictional mirage”. If a breach happens in orbit, it is unclear which regulator has authority to investigate, and that ambiguity cuts against any vendor selling sovereignty as solved.
Run the sovereignty argument through the same scrutiny as every other claim. Confirm in writing where your data sits legally, who can audit it, and which regulator has jurisdiction. Watch for greenwashing, which critics already attach to some orbital pitches. Sovereignty workloads are a real but narrow slice of latency-tolerant inference, and for the right workloads the premium may be worth paying. Just do not accept it as a given.
Conclusion
The outcome turns on whether your workload fits and whether the vendor can prove the claim. Build versus buy becomes a workload-fit question, the timing decision keys off cost parity, and vendor credibility becomes the binding constraint on any commitment.
Even sovereignty has to survive the question of whether orbit buys anything you could not get on the ground. The 2026 land rush is a reason to keep watching rather than commit.
Frequently Asked Questions
Is orbital compute actually cheaper than terrestrial capacity yet?
No, not close. Independent cost models put space compute at roughly four times the levelized cost of terrestrial capacity today, and parity is generally modelled around 2040, if it arrives at all. The gap is driven by launch costs and a short five-year asset life against fifteen years on the ground, not by any inherent efficiency of orbit. Treat any near-term cost-parity claim as unproven.
Will orbital data centres eventually replace terrestrial ones?
Unlikely. The credible framing is complementary, not replacement: orbit suits a subset of workloads, and even bullish analysts model it capturing only 10 to 15 per cent of the AI data centre market by 2040. Terrestrial capacity stays the default for latency-critical and tightly coupled work. The strategic question is which workloads belong in each environment, not whether one displaces the other.
Which of my AI workloads should stay firmly on the ground?
Anything that needs millisecond responsiveness stays terrestrial. Interactive assistants, autonomous systems, real-time fraud detection and most customer-facing services cannot absorb the added round-trip latency of low Earth orbit. Large foundation-model training also stays grounded, because it needs tightly coupled clusters and power densities orbit cannot match. Batch inference, scheduled analytics, scientific simulation and back-office AI are the credible orbital candidates.
Can a small team use orbital compute without building a satellite?
Yes. A small team buys capacity or a hosted payload from an early provider rather than owning the physics. Building an orbital data centre demands capital, launch access and in-space engineering that few organisations possess, so the realistic path is to procure capacity or run a tightly scoped pilot. This lets you test fit without carrying launch risk, radiation design or thermal management on your own balance sheet.
What is the levelized cost of compute (LCOC), and why does it matter?
LCOC is the net cost of useful compute delivered to a service-level agreement, expressed per GPU-hour or per PFLOP-hour. It matters more than a headline $/W figure because it accounts for availability and redundancy: orbital systems carry roughly 20 per cent spare capacity for failures they cannot repair, so their LCOC sits well above plain total cost of ownership. Ask any vendor for LCOC, not capital cost.
Is cooling in space really free?
No. Space is cold, but a vacuum has almost nothing to conduct heat away, so cooling becomes a mass-and-area problem rather than a free lunch. Waste heat must be radiated from large panels, and that hardware adds cost, weight and complexity. When a vendor describes cooling as free, or solar as free, treat it as a red flag that the underlying physics has not been reconciled with the numbers.
What happens if an orbital compute node fails mid-contract?
Failures are absorbed by redundancy rather than repair. Orbital chips cannot be serviced by a technician, so providers budget roughly 20 per cent spare capacity and plan to deorbit and replace failed nodes. That is a cost and lead-time commitment you should see reflected in the contract and the service-level agreement. If a provider cannot explain its failure and replacement model, the pricing is not yet grounded.
How is orbital compute priced, and which unit should I compare?
Vendors often quote $/W while analysts quote $/GPU-hour or $/PFLOP-hour, which makes comparisons misleading. Insist on a single unit tied to your workload, ideally cost per GPU-hour or per billion tokens at a defined service level, so the orbital figure sits beside your terrestrial benchmark. Converting every claim to the same denominator is the fastest way to expose a number that does not survive scrutiny.
If my data is processed in orbit, which laws govern it?
This is genuinely unsettled. The 1967 Outer Space Treaty leaves the satellite under the launching state’s supervision, while terrestrial rules such as the GDPR or India’s DPDP Act still claim the data itself. That jurisdictional ambiguity is exactly why sovereignty claims need testing: confirm in writing where your data sits legally, who can audit it, and which regulator has standing before you commit.
How long should a structured pilot run, and what should it prove?
Treat the pilot as a time-boxed learning exercise, not a soft launch. It should prove three things: real workload throughput against your benchmark, sustained operation under radiation and eclipse cycles, and a cost per unit that matches the vendor’s claim. If a provider resists defining measurable acceptance criteria up front, that reluctance is itself a finding. Only evidence turns a vendor claim into a testable requirement.
Do I need radiation-hardened chips to run AI in orbit?
Not necessarily. The consensus has shifted toward shielded commercial silicon with architectural hardening such as ECC memory and watchdogs, rather than expensive rad-hard processors. That change lowered the feared hardening premium from five to ten times down to a low-single-digit multiple. Ask for beam-test evidence and flight history anyway, because a passing ground test is not the same as years of cluster-scale operation.
