Data centers go orbital

Rising above power, heat & permitting limits

Data center development is running up against seven-year power queues, water scarcity, and regulatory resistance. Meanwhile, orbital compute has moved from concept to operational status, with recent GPU-in-space demonstrations proving viability. For workloads where continuous solar power, passive cooling, and geopolitical resilience matter more than millisecond latency, low Earth orbit (LEO) satellites offer a way to bypass terrestrial bottlenecks.

THE BOTTLENECK HAS MOVED BEYOND THE DATA HALL

AI infrastructure is colliding with physical limits. Constraints are now measured in megawatts, thermal capacity, water availability, and regulatory timelines in addition to server racks. For example, EU data centers are expected to represent 4% of the region’s electricity demand (~108 TWh) by 2030, the equivalent of more than 10 nuclear reactors operating at 1,200 MWe. That is more than the current annual electricity consumption of the Netherlands.

Power constraints are dominating data center–building timelines, with multiple-year utility interconnection queues in many major hubs. In Northern Virginia, USA, new-connection waits can be up to seven years. With AI model generations turning over every 12-18 months, that timeline is commercially untenable. Thermal management introduces additional constraints. Water-based cooling systems substantially increase local consumption, and water-stress exposure affects numerous data center regions, elevating operational and reputational risks for developers.

Regulatory hurdles compound these physical limitations: community resistance has matured from isolated opposition into a systematic scheduling risk, dramatically extending project timelines and increasing stakeholder management costs. Even alternative power strategies face difficulties: developers pursuing natural gas prime power are facing turbine procurement backlogs of seven years in some markets.

These constraints matter because AI economics reward speed: infrastructure that arrives after the model-refresh cycle delivers diminished returns. Fortunately, orbital compute is transitioning from concept to operational status. A recent demonstration successfully tested an H100-class GPU payload in space, marking a tangible step toward space-based AI infrastructure.

WHAT ARE ORBITAL DATA CENTERS?

Satellites in LEO operate at altitudes of 400-1,400 km above the Earth’s surface. Unlike geostationary satellites (fixed at ~36,000 km), LEO assets travel around the Earth every 90-120 minutes, enabling near-continuous solar exposure in certain orbital configurations and lower communication latency than deep space deployments. Orbital data centers are compute hardware (processors, memory, storage) hosted aboard these satellites.

The vision for orbital data centers is not hyperscale facilities in space. Rather, it’s a modular, networked layer of compute satellites designed for workloads where orbit provides structural advantages, such as near-continuous solar exposure (with a low orbit close to 1,400 km), a passive thermal environment, proximity to space-generated data, and/or geopolitical resilience (see Figure 1). Additional benefits include the scale effect of similar modules, mass optimization, and compatibility with a launcher’s capacity and volume.

Most early space-based applications fall into one of the following three categories:

1. In-orbit edge compute — processes data at the source, including Earth observation imagery, radio frequency signals, and spacecraft telemetry; downlinks actionable insights rather than raw datasets to reduce bandwidth requirements and accelerate decision cycles.
2. Resilience and sovereign storage — maintains off-planet archives of critical datasets, model checkpoints, and immutable logs for continuity scenarios where terrestrial redundancy is insufficient.
3. Latency-tolerant batch compute — executes training runs, simulations, or analytics workloads that prioritize energy availability and isolation over millisecond responsiveness.

6 CRITICAL BUILDING BLOCKS

Even as the hardware advances, the success of orbital data centers requires systems engineering rigor across six important building blocks:

1. Power — continuous solar at scale. Certain orbital regimes (e.g., dawn-dusk Sun-synchronous orbits) can provide near-continuous solar exposure, particularly at higher LEO altitudes (1,200-1,400 km). However, high-specific-power, radiation-tolerant solar arrays, and resilient energy storage are needed to handle transients and contingency eclipse events within strict mass and reliability constraints.
2. Thermal — radiate, don’t evaporate. Even for satellites illuminated by the Sun, a few minutes of shadow occur during each orbit, leading to a temperature spread from +120°C to -250°C. Thermal management — both within the satellite and in releasing heat into space — is therefore critical and directly influences platform sizing. Efficient thermal management, including heat spreading, conservative power density, and intelligent workload scheduling, becomes a key performance determinant.
3. Compute — resilient, modular accelerators. Radiation hardening, redundancy, and autonomous operation are baseline requirements. Because AI economics depend on hardware-refresh cadence, platforms need upgrade pathways, swappable units, and servicing strategies to maintain high utilization rates.
4. Network — high-throughput space-to-space and space-to-ground links. Value is only unlocked when data moves efficiently. For non-geostationary modules, optical inter-satellite links are needed to exchange data before transmitting it to Earth. Robust, scalable ground gateways are also required to receive large data volumes and route insights securely, reducing the need to transmit unprocessed data.
5. Launch economics — reusable heavy-lift access. Reusable launch systems like SpaceX’s Starship, which targets sub-$100/kg versus historical rates of $2,000-$10,000/kg, are fundamentally reshaping orbital data center economics by making mass-intensive designs, redundancy, and iterative deployment commercially viable. Launch costs currently account for about 40% of total investment and depend heavily on architecture choices, including direct injection into final orbit, launch to a parking orbit, and use of a transfer vehicle. In all cases, a mega launcher like Starship is required due to its competitive launching costs and onboarding capacity.
6. In-orbit assembly and servicing. Large orbital data centers require robotic assembly of modular units and periodic hardware refresh. Standardized docking interfaces and autonomous operations determine whether or not platforms can scale beyond demonstration missions to multi-rack facilities with a competitive refresh cadence. Minimizing these in-orbit services may help reduce time to market but may increase the number of satellites needed.

HOW USERS WILL ADOPT ORBITAL COMPUTE

Orbital data centers may sound more visionary than they actually are. Rather than fully migrating to space, operators will deploy a new data channel (much like the one emerging in mobile communications with OneWeb, Starlink, and Kuiper) and use orbital capacity only where it removes a greater bottleneck than it introduces.

Satellite operators and defense users can execute preprocessing and inference in orbit, shrinking downlink volumes while accelerating targeting, alerts, and situational awareness. Critical archives and immutable audit logs stored off-planet provide extreme continuity protection and tamper resistance beyond terrestrial geography. Select training, simulation, and analytics workloads that tolerate higher latency can leverage continuous solar energy, bypassing terrestrial interconnection queues and generation-equipment scarcity. Cloud providers, colocation operators, and aerospace firms might offer orbit-adjacent products like processing, storage, or secure compute, integrating with ground regions as differentiated offerings, while patterns for distributed inference and secure model updates create reusable building blocks.

Orbital computing is edge AI at altitude: it runs inference where the data originates, processing raw imagery, radio frequency signals, and telemetry in orbit and downlinking only what matters (i.e., decisions, alerts, and compact feature outputs rather than raw streams). This cuts bandwidth demand and tightens the loop from observation to action. The architectural logic mirrors the shift already driving edge AI across factories, autonomous vehicles, and distributed sensor networks, where pushing raw data to a central cluster is increasingly untenable at scale.

Organizations building those terrestrial pipelines are already developing the core primitives that extend naturally to orbital deployments: distributed orchestration, secure model updates, observability under intermittent connectivity, and policy-driven autonomy. These infrastructure investments are not parallel bets; they are the same architectural bet deployed across different environments.

CHALLENGES & OPPORTUNITIES

This opportunity is tangible, but constraints remain. For starters, launch costs, platform mass, utilization rates, and operational lifetime must exceed the avoided costs of terrestrial delays such as power, water, permits, and timeline risk. Second, autonomous fault management, debris management, credible servicing pathways, and upgrade strategies will determine refresh cadence and effective cost per compute hour. Third, orbital availability, spectrum allocation, and cybersecurity frameworks will shape deployment speed, permissible actors, and operational boundaries.

Increasingly, the data center industry’s constraints are external to technology. Orbital compute will not eliminate every bottleneck, but for specific workload classes, it offers a way to avoid power queues, heat limits, and permitting timelines by converting physical constraints into architectural opportunities. We advise companies to architect orbital compute as a complement to terrestrial infrastructure, not a replacement, leveraging each environment’s comparative advantages and planning now to capture first-mover advantages.

Conclusion

FROM BOTTLENECKS TO LAUNCHPADS

We recommend disciplined exploration rather than premature commitment to capture early strategic advantage. Given current vendor roadmaps and recent orbital GPU validations, commercial platforms are likely five to seven years out. SpaceX has expressed interest in extending its Starlink architecture to create large-scale, solar-powered orbital compute infrastructure for AI workloads. This signals early positioning for space-based capacity, even with practical deployment several years away. Recommended steps include:

1. Identify orbit-native workloads. Map latency-tolerant processes, space-data pipelines, and resilience-critical datasets that align with orbital capabilities.
2. Quantify avoided bottlenecks. Weigh downlink savings, resilience value, and time-to-power benefits against orbital deployment costs.
3. Pilot with strict requirements. Engage early providers using rigorous security, operability, and performance benchmarks. Treat initial deployments as structured learning exercises.