Will We Put Data Centers in Space?

Abstract

Introduction & Takeaways

Image

• SpaceX's Starship is the only vehicle currently on track to deliver the launch costs and cadence that meaningfully scaling orbital data centers would require. Competitors are years behind, making SpaceX’s Starship the only near-term path to large-scale orbital compute. SpaceX aims to complete Starship development by late 2026, with several necessary milestones still ahead. If development stays roughly on track, Starship could plausibly hit the cost and cadence required to scale meaningful orbital compute within 3–5 years. However, chip production may become the limiting factor by this point, rather than launch capacity.

• The cooling problem is more tractable than commonly assumed. Passive radiators using selective coatings and lightweight carbon fibre panels could achieve ~163–346 W/kg at system level, a 13-28× improvement over ISS-era radiators (~13 W/kg).5 No radiator at these performance levels has been deployed at the scale an orbital data center would require, but prototype high-conductivity carbon composite panels have demonstrated the material properties required. At these performance levels, thermal hardware is 2-5% of total data center cost, and actually less than what terrestrial data centers spend on cooling over a comparable lifecycle.

• If launch costs fall enough, the unit economics could favor space. Solar panels in dawn-dusk sun-synchronous orbit produce roughly 3–5× the energy of the same panel at a good terrestrial site.6 Space-based solar becomes cheaper than the best off-grid terrestrial installations once launch costs drop below roughly $250/kg using Starlink-like solar arrays. At a launch cost of $50/kg (corresponding perhaps, to a Starship with full reuse as reliable as Falcon), space solar could fall to between $25–45/MWh, making it cheaper than any current terrestrial option available today.7 Beyond the symmetric cost of chips, launch cost is the dominant line item for ODCs while power and op-ex dominate terrestrial costs but would be near zero in space.

• The inability to do maintenance would be a large cost. Chips often fail and are swapped out in today’s data centers but a dead chip in an ODC would remain dead, wasting the parts of the supporting infrastructure (power, cooling) and diminishing overall compute. We model this below as a 9% annual bleed causing about 40% overbuy of launch and non-chip hardware over the data center's lifetime.8 Below $100/kg launch cost this might net out against other savings from ODCs but this is a significant uncertainty since the actual rates of chip failure for ODCs could be higher or lower.

• All-things-considered we think that, absent transformative AI, orbital data centers probably won’t make up a meaningful fraction of compute before 2030, but it's credible that space could house much or even the majority of compute buildout throughout the 2030s.

The basic economic case for orbital data centers

Image

Image

Launch lead times and scaling rates depend on Starship

Where Starship stands today

While competitors appear several years behind

What does Starship reusability mean for launch cost?

How long would it take for ODCs to scale?

• The turnaround time for each Starship. This is the time to catch, restack, load cargo and refuel the Starship before launching again, where SpaceX targets 3x/day. SpaceX’s current record turnaround is 9 days, but this being with Falcon rather than with a fully reusable vehicle. As for a rough lower bound: commercial airlines typically run 3-7 flights a day, with turnaround times of perhaps 1–2 hours. Still the limits of reusable heat shields are not known and the floor for turnaround might be much higher. We’ll use a 1x/day turnaround for our fast scenario and a 6 day turnaround for our slow scenario.

• We’ll use a 1x/day turnaround for our fast scenario and a 6 day turnaround for our slow scenario.

• The time to construct new rocket factories and ramp their production. SpaceX has two Gigabay production facilities under construction (Boca Chica and Roberts Road, FL), both targeting completion by end 2026, but it's too early to tell what growth rates will be based on this. An apt comparison could be to Tesla, which opened 5 Gigafactories between 2016 and 2022, a pace of roughly one new major factory every 14 months. Construction times also fell sharply over this period: Giga Shanghai was completed in just 168 working days, roughly a third of the typical automotive factory build time. We’ll assume SpaceX builds 1 new factory over the next ~4 years of Starship R&D for our slow scenario and that SpaceX builds 2 new factories over the next 2 years in our fast scenario.

• We’ll assume SpaceX builds 1 new factory over the next ~4 years of Starship R&D for our slow scenario and that SpaceX builds 2 new factories over the next 2 years in our fast scenario.

• The number of rockets/factory/year produced. SpaceX has discussed an eventual goal of producing ~365 Starships per year (~1/day). As a useful anchor, Boeing’s mature 737 program produces on the order of ~38–42 aircraft per month today, though this rate is currently capped by the FAA following quality issues, and historically has reached higher levels. An airliner contains on the order of hundreds of thousands of parts, whereas Starship’s stainless-steel architecture is relatively simpler. However, Boeing benefits from decades of production tooling and supply-chain maturity. SpaceX’s Falcon-9 ramp could also be illustrative. Early production went from about 25 rockets in 2020 to 165 by 2025. We’ll assume SpaceX can build ~1–10 rockets every 2 months from a given factory floor for our slow scenario or ~1–20 starships per month for our fast scenario.20

• We’ll assume SpaceX can build ~1–10 rockets every 2 months from a given factory floor for our slow scenario or ~1–20 starships per month for our fast scenario.20

• Slow ODC takeoff scenario. In this scenario, Starship reaches rapid reusability mid-2030 having suffered many setbacks. SpaceX builds just one additional gigabay over the ~4.5 year development cycle of Starship, then begins to ramp production. By 2031, 3 gigabays have produced a total of 18 Starships but turnarounds are slow, requiring 6 days of downtime after each flight. The first meaningful tranche of orbital compute is deployed throughout 2031 and totals around 1,095 launches amounting to roughly 4 GW of orbital compute. Meanwhile forecasts expect perhaps 100 GW of terrestrial data center buildout by 2030. Thus, orbital compute makes a negligible fraction of total compute until perhaps later throughout the 2030s.

• Fast ODC takeoff scenario. In this scenario, Starship begins deploying Starlink V3 satellites in 2026 and reaches rapid reusability by 2027. SpaceX then builds out 2 new gigabays by EOY 2027 and ramps production variously across 4 facilities, producing at least 48 Starships by early 2028. By this point Starships are produced at one Starship per month on average, as contrasted with Boeing's ~38 planes per month or Tesla’s production of ~10,000+ cars per month from a single factory floor. Throughout the year, the growing fleet manages a total of 10,000+ launches. By EOY 2030, up to 100GW of orbital compute is operational.22

Is thermal management a dealbreaker?

Open problems and disadvantages

Chip Failure

Bandwidth and ODC Architectures

Image

• Constellation model (SpaceX, Google, Blue Origin). A fleet of individual satellites, each equipped with GPUs, orbiting independently. This leverages SpaceX's existing mass-production capability and could be relatively quick to deploy. The unsolved limitation is bandwidth: today's commercial inter-satellite optical links deliver on the order of 1 to 100 Gbps over thousands of kilometres, which is orders of magnitude short of what tightly coupled ML training clusters require. Google's Project Suncatcher proposes packing satellites into tight clusters (kilometre-scale or sub-kilometre-scale separations rather than thousands of kilometres) and using optical links similar to terrestrial fibre technology. At short distances, the physics of free-space optics improves somewhat, and Suncatcher suggests bandwidths on the order of 1–2 Tbps per transceiver pair may be achievable. This is an interesting idea, but it shifts the challenge to maintaining dense satellite formations with precise pointing and tracking.

• Modular station model (Starcloud). A central spine structure with docking ports, to which compute modules (roughly 40 MW each) are launched and physically attached, connected to a large solar array. This sidesteps the bandwidth problem entirely, since modules are physically connected. However, it is further from what existing manufacturing and launch capabilities can deliver so this is a longer term vision, and introduces engineering challenges around structural integrity at scale. We found Starcloud's published cost estimates to be overly optimistic compared to our assessment, though it’s possible Starcloud has one or more clever engineering tricks in mind while we did not try hard to optimize beyond today’s space hardware. The concept may also become more feasible after continued investment in space-based infrastructure.

• Inference is a natural fit for orbital compute. Modestly equipped satellites could serve inference workloads where each request is independent. Latency from LEO to the ground is also modest at a few milliseconds.

• Training looks harder. Frontier runs synchronize gradients across thousands of GPUs at every step, demanding sustained bandwidth between nodes that dwarfs current inter-satellite links. Even Suncatcher's proposed 1–2 Tbps, if achieved, would need to connect enough satellites to match the bisection bandwidth of a terrestrial cluster. The modular station model avoids this by physically connecting modules, but at the cost of in-space assembly no one has yet attempted.

Radiation

• Cumulative damage appears to be well within chip tolerances. Google tested their Trillium TPU and found no hard faults up to 15 krad, roughly 20 times the expected 5-year shielded dose at 550 km.33 Shielding is cheap relative to what it protects.34

• Transient bit flips are more nuanced. Standard error-correcting codes handle virtually all single-bit errors, with uncorrectable errors estimated at roughly 0.01 to 0.1 per GPU per year.35 For inference workloads, this seems likely to be negligible: model weights are read-only, can be periodically reloaded, and neural networks are inherently noise-tolerant. For training, the picture is somewhat murkier. Corrupted gradients might propagate through the model, and a single undetected multi-bit error during a long training run might in principle corrupt a checkpoint. On the other hand, no single node holds the full state during a distributed training run, which provides some natural resilience and errors could later be ironed out over the training run. Also, this may be simple to solve with error correcting codes. Overall, we don’t expect this to be a problem.

• Error correcting codes can scale to ensure reliability, at the cost of redundancy. Standard SECDED codes add ~12.5% storage overhead and negligible compute cost, while stronger chipkill-class or symbol-based codes increase overhead by tens of percent to tolerate multi-bit or device-level failures. It seems likely that reliability can be ensured at low cost; but there is as yet little data, and we aren’t too confident.

Congestion in Orbit

• Debris and micrometeors pose a modest threat. Starlink's empirical record shows zero confirmed failures due to debris strikes across roughly 27,000 satellite-years of cumulative exposure.36 SpaceX performs over 300,000 autonomous collision avoidance manoeuvres per year fleet-wide (around 35–40 per satellite per year), a capability directly transferable to space data center modules. And per-satellite risk doesn’t grow with the overall scale of ODCs; so we think this isn’t a meaningful issue.

• Orbital crowding is a more systemic concern. SpaceX's FCC filing proposes up to one million satellites, roughly 50 times the current total number of satellites across all orbits — concentrated in sun-synchronous orbit, one of the most debris ridden orbital regions.37 Today's debris tracking infrastructure and traffic coordination experience suggest this could be feasible. However, past collisions and anti-satellite tests have produced debris fields lasting decades38, and adding satellites at this scale raises the risk of Kessler syndrome, a runaway cascade of collisions that could render orbital bands unusable. We don’t think this is likely to be a major blocker to placing a meaningful fraction of AI compute in orbit, but it will require more effortful and sophisticated traffic management and eventually cleanup tech (see ‘Space Debris and Launch Denial’.)

Supply chain immaturity

Non-cost factors

Regulation and permitting

• Traditional data centers face several regulatory and supply constraints but none are currently binding. On the terrestrial side, several frictions can slow deployment. Grid interconnection queues stretch to 5 years in many US regions. The most promising workaround appears to be on-site microgrids (solar, battery, and gas turbine systems that sidestep the grid queue entirely), combined with prefabricated modular construction.39 This approach can compress lead times significantly, as xAI demonstrated by bringing its Memphis facility online in 122 days.40 Community opposition has also become a factor, with one industry tracker estimating over $98 billion in US projects blocked or delayed by local resistance as of mid-2025.41 In our cost comparison, we benchmark against this off-grid microgrid strategy as the most competitive terrestrial alternative, using one case with solar+gas, and another solar+battery storage for continued scaling in case gas turbine bottlenecks bite. Altogether, permitting and regulatory constraints don’t currently seem binding, but they are increasingly becoming a headache.

• Orbital data centers could scale fast, but only if the regulatory regime looks as favorable in a few years as it does today. Orbital data centers sidestep terrestrial permitting entirely. The advantage of building satellites seems to be that you only have to deal with one regulatory regime once, and then you can launch satellites continuously on that basis; whereas every single terrestrial AI data center must be shepherded through many layers of regulatory approval. However: current FAA site approvals cap Starship at 145 launches per year This is well below what meaningful orbital buildout would require, amounting to perhaps ~0.5 GW/yr launched.42 But we think it’s more likely than not that this doesn’t block ODC buildout, especially because the current US administration is actively favourable to commercial space. Two recent executive orders, Enabling Competition in the Commercial Space Industry (August 2025) and Ensuring American Space Superiority (December 2025), direct agencies to eliminate or expedite environmental reviews for launch licensing and to bolster the commercial space industry. Orbital deployment runs through a small number of federal agencies (FAA and FCC) moving to reduce friction, while terrestrial buildout must navigate a patchwork of local authorities. Of course, regulatory environments change. If the economic or strategic value of terrestrial data centers become politically salient, permitting could be expedited, or waived-permitting zones could be set up. On the other hand, even if the current FAA launch cap is lifted, raising by the order of 100x needed to compete with terrestrial data center buildout could spark new political opposition. And although the current US administration is sympathetic to space industry, a new admin and hence new FCC chair and FAA head may be more inclined to scrutinise SpaceX’s requested ODC waivers.

Physical and cyber security

• ODCs eliminate several of the cyber attack vectors, but may still be vulnerable. RAND's framework for securing model weights identifies attack vectors for model security, with insider threats and physical access among the hardest to mitigate. No existing facility achieves the highest tier (SL-5, robust against top-priority nation-state operations), and the SL-5 Task Force estimates it would take at least five years and substantial government support to reach. ODCs remove the physical access and insider threat categories almost entirely, i.e. no humans on site, no USB ports, no maintenance visits. The ground segment remains the weak link however. Uplink stations, mission control, and the pre-launch supply chain are all vulnerable to the same cyber and supply chain attacks that threaten terrestrial facilities. The 2022 Viasat hack, which disabled thousands of modems across Europe via a single ground-segment exploit, illustrates how ODCs would not eliminate the threat of cyber attacks.43

• Jamming can limit communication with the ground, but there are defenses. Russia deployed battlefield jammers against Starlink in Ukraine in 2022, but SpaceX responded with software updates for hopping frequencies, largely neutralising the disruption. Iran's more sophisticated 2026 campaign combined GPS spoofing and multi-band RF jamming (using Iran's Cobra-V8 electronic warfare system, comparable to Russia's Krasukha-4), driving packet loss above 80%. SpaceX again adapted, reducing loss to around 10% in some areas, but this time they did not fully restore service.44

• The implications of kinetic strikes are severe. Presently, Anti-satellite weapon (ASAT) costs (tens of millions each) exceed satellite replacement costs (low millions each), and each intercept generates debris threatening the attacker's own assets (and international uproar). However, a sufficiently reckless actor (or an actor with little to lose in terms of space assets) could threaten to release debris in an orbital shell, taking out many data centers at once. This possibility argues for stronger international norms against kinetic ASAT weapons, which the US has endorsed via a 2022 moratorium on direct-ascent testing, but arms control negotiations around ASAT weapons have been mostly gridlocked in recent years.45

• EMP and nuclear ASAT weapons are possible, but drastic. A nuclear detonation in orbit might disable or destroy a number of satellites or even degrade an entire shell via artificial radiation belts. But this would also affect every nation's satellites indiscriminately, risk all-out Kessler syndrome, clearly violate the Outer Space Treaty, and likely trigger forceful retaliation. It is the orbital equivalent of salting the earth.

• Close-range means of disabling satellites avoid debris but would require significant investment to scale to disable whole constellations. Both China, the U.S., and Russia are developing co-orbital vehicles capable of approaching satellites for inspection or close-range destruction, and the DIA assesses that China is actively pursuing directed energy weapons for counterspace applications, including high-powered microwave systems that could disable electronics without generating debris. The offense-defense balance at the constellation level appears to favour the defender, since each engagement requires dedicated orbital manoeuvring while the defender launches replacements in batches, but the margin depends on the attacker's willingness to invest in dedicated counter-space capability at scale. As for co-orbital exfiltration: ODC satellites can be designed with no docking ports, no external data interfaces, and no removable storage, we think, making physical data extraction fairly infeasible.

• The pre-launch supply chain and ground-side connections remain a vulnerability but may be easier to secure than Earth-based data centers. Satellites must be assembled and integrated on Earth, exposing them to insider and supply chain threats that RAND's SL-5 framework is designed to address. A possible mitigation could be to launch satellites "empty" and train in space or upload weights via encrypted link after reaching orbit, then ensure the operational model never requires weights to be downlinked.46

Conclusions

• Starship would need to achieve rapid reusability, and probably hit launch costs at or below $100/kg

• The FAA would need to approve increases in annual launches, likely requiring new launch sites. The current 145-launch ceiling for Starship would need to increase at least 35-fold, plausible under the current administration's posture, but substantial.

• Chip failure for ODCs would need to be comparable to Earth-based data centers. Early ground testing is encouraging, and we account for ~9% per year compute bleed in our cost breakdowns, finding space competitive at low launch cost despite this steep penalty. NVIDIA's Space-1 chip and subsequent generations may bring improvements; however, true failure rates in orbit are unknown and could be much worse than we estimate.

• A space-based architecture with high-bandwidth interconnects for frontier training is demonstrated, or inference demand alone justifies the investment. Without high bandwidth interconnects, orbital compute may be limited to inference and loosely coupled workloads, which could be a large hit to the value proposition of ODCs.

Appendix A: Radiation environment

• ~150 rad(Si) per year at 550 km sun-synchronous orbit (Google Suncatcher reference case), giving a 5-year mission dose of ~750 rad(Si).

• ~1–2 krad per year at 800 km, substantially worse.

• ~50 rad per year at 400 km (ISS-like), more benign.

Appendix B: Degradation and system wear

• Triple-junction space-rated cells degrade very slowly. On-orbit data from the Gaofen-3 satellite shows roughly 0.18% per year power loss, or about 1.4% total over 8 years. These cells are designed for 15+ year missions.

• Commercial silicon cells degrade significantly faster. Our model uses 8% per year compound degradation, consistent with Lupo et al. (2025), who report 10–15% Si cell degradation in the first 6 months at ~500 km for CubeSats with minimal coverglass (annualizing into a multi-year compound average near our assumed rate). This gives an end-of-life power fraction of 65.9% after 5 years ((1−0.08)⁵ = 0.659). The array is oversized by 1/0.659 = 1.517× at beginning of life to guarantee rated power at end of life, with the excess energy in early years captured in the LCOE calculation.

• The cost savings are roughly two orders of magnitude per watt, which at scale substantially affects the economics.

• Attitude control is the biggest mechanical reliability risk in typical spacecraft, contributing roughly 20% of all failures. Reaction wheels are the most common failure point due to continuous motor wear, though this is typically on longer timescales (Hubble's lasted roughly 15 years; commercial wheels are rated for 15+ years). Space data center modules would have simpler pointing requirements than a telescope, so this is likely no novel challenge over a 5-year lifecycle.

• Batteries face extreme cycling in low Earth orbit (roughly 16 charge/discharge cycles per day, roughly 30,000 over 5 years), but if orbital data centers operate in near-continuous sunlight (sun-synchronous orbit), battery cycling demands drop dramatically.

• Starlink uses argon Hall thrusters rated for their 5-year mission life. It seems similar systems could be adopted for space data center modules with comparable reliability profiles.

Appendix C: Space weather

• Electromagnetic radiation (X-rays/UV) arrives in roughly 8 minutes and can disrupt sensors.

• Solar energetic particles (protons) arrive in roughly 1 hour and cause intense bursts of single event upsets and accelerated cumulative radiation damage.

• The coronal mass ejection plasma cloud arrives in 18 hours to days and heats the upper atmosphere, increasing drag on low Earth orbit spacecraft.

Appendix D: Solar cost crossover

Space side: two solar scenarios

• EOL fraction = (1−0.08)⁵ = 0.6591, oversize = 1/0.6591 = 1.517,

• BOL peak power per kW-continuous = 1,597 W.

Earth side: two baselines

Sensitivity to battery cost

Appendix E: Thermal management

Appendix F: Environmental footprint

• Land use favours space, though orbital slots are a somewhat finite resource too. A solar-powered 100 GW terrestrial buildout would require roughly 5,000 to 10,000 km² of land, primarily for generation rather than the data centers themselves.48 The same capacity in orbit implies a many-fold increase over today's active population of more than 11,000 satellites. Our guess is that such an increase in the satellite population would be sustainable with some concessions, like by placing satellites in (slightly more expensive) higher orbits to keep congestion manageable.49

• Water consumption is often cited as an advantage for orbital data centers but AI water usage seems relatively minimal. Space is somewhat advantaged with near zero water use. However, even if current data center capacity were scaled 100x in the US, it would likely still account for a relatively small fraction of total US water consumption. Claims about the environmental harms of data centers specifically relating to water use seem somewhat overblown (both in absolute terms, and compared to other environmental harms, like carbon emissions).50

• Carbon emissions favour ODCs over grid-powered terrestrial data centers, but not over renewable-powered data centers. The marginal carbon emitted by building and replacing an orbital constellation is roughly 20 to 45 times lower than the yearly operational emissions of a gas-grid data centre, but only around 2 to 5 times less carbon-intensive compared to off-grid solar with partial gas backup.51 A fully renewable terrestrial facility would be cleaner still. In fact, for much of the undeveloped desert land where terrestrial solar farms would ideally be sited, the panels could even be a net environmental positive, since shade structures in arid environments increase total biomass and can help reverse desertification.

• Stratospheric soot from rockets is negligible at current launch rates but may later become meaningful at the thousands of Starship-class launches required to build a 100 GW constellation, with full replacement every five years.52 It’s worth noting that Starship is powered by methane and oxygen, which (although not as clean-burning as hydrogen and oxygen) produces less soot than most historical chemical rockets.

• Satellite reentry pollution could pose a novel risk, if proven dangerous. Current mega-constellation plans consisting of thousands of satellites would deposit many tonnes of aluminium oxide per year in the stratosphere when deorbiting at the end of their life-cycle. Orbital data centers at scale, e.g. 100 GW imply 30 to 70 times that level, potentially with cascading effects on ozone, mesospheric temperatures, or polar vortex dynamics, according to a growing body of research (see here and here).53 If this threat proves credible, it may be necessary to maneuver decommissioned satellites into a graveyard orbit, either by towing them, or requiring them to boost themselves into the graveyard orbit. Towing has been demonstrated, but not at scale; while de-orbiting boosts would increase the propulsion requirements for the whole mission, especially from higher altitudes.

Footnotes