June 15, 2026
Orbital data centers are usually sold as an energy story: put compute where sunlight is abundant, avoid terrestrial grid constraints, and beam the results back to Earth. Astronomers are asking the harder question: what happens when data-center-scale spacecraft become part of the sky?
That question is now urgent because orbital computing is moving from white papers into corporate strategy. SpaceNews reported that astronomers fear orbital data centers could interfere with observations as SpaceX prepares to launch large AI-compute spacecraft [1]. The concern is not anti-technology reflex. It is a practical warning from a community that has already spent years dealing with the optical and radio effects of satellite megaconstellations.
The STC read: orbital data centers may become a real infrastructure category, but they need astronomy and orbital-environment requirements from the start. It will be much harder to retrofit the sky after thousands of bright, electrically noisy spacecraft are already on orbit.
Why data-center satellites are different
A communications satellite has antennas, radios, power systems, attitude control, thermal control, and a payload built around moving information. An orbital data center has all of that plus high-power computing hardware, large solar arrays, significant thermal rejection hardware, and sustained data links sized around compute workloads.
That changes the interference problem.
Recent reporting on SpaceX’s AI1 concept described a first-generation orbital data center satellite with a roughly 70-meter span, rack-mounted AI chips, liquid radiators, and a compute payload reportedly averaging around 120 kW and peaking near 150 kW [2]. Other reporting described an 11-million-square-foot “Gigasat” factory concept in Bastrop, Texas, aimed at manufacturing AI satellites and reaching gigawatt-scale orbital compute output [3].
Those numbers should be treated as reported company-ambition figures, not proven operating performance. But even as aspirations, they are enough to show why astronomers are paying attention.
Large solar arrays and radiators can reflect sunlight into optical telescopes. High-power electronics can generate unintended electromagnetic radiation. Downlinks and inter-satellite links can complicate radio-frequency coordination. A spacecraft built to run and cool a data center is not just another small broadband node.
It is a bright, power-dense machine in an orbital environment that is already difficult to manage.
The sky is already an operating environment
The astronomy community’s concern did not begin with orbital data centers. The International Astronomical Union’s Centre for the Protection of the Dark and Quiet Sky has warned that satellite constellations can affect both optical and radio astronomy. Its 2024 call to protect the dark and quiet sky says satellite constellations reflect sunlight into optical telescopes and their radio emissions affect radio observatories, with global effects that cannot be avoided simply by moving to a different site [4].
Radio astronomy is especially sensitive because it listens for extremely faint signals. Radio quiet zones help protect telescopes from ground-based interference, but they do little against satellites passing overhead. A 2023 study using the LOFAR radio telescope detected unintended electromagnetic radiation from Starlink satellites between 110 and 188 MHz. The authors reported detections associated with 47 of 68 observed satellites and noted a regulatory gap around emissions that are not tied to intentional communications [5].
That is a warning sign for orbital data centers. A compute satellite is full of high-speed electronics, power conversion equipment, buses, clocks, switching circuits, thermal systems, and radios. Each system can be well engineered and still create aggregate electromagnetic behavior that matters to sensitive observatories.
The challenge is not that every orbital data center will be harmful by default. The challenge is that nobody should have to discover harmful emissions after deployment at constellation scale.
The engineering case is still unsettled
Orbital compute has a real attraction. Space offers stronger solar irradiance than Earth’s surface, long periods of sunlight in certain orbits, and freedom from some terrestrial siting constraints. For latency-tolerant or space-native workloads, putting compute near space-generated data can make sense.
But the engineering case is narrower than the hype suggests.
An April 2026 paper by Slava G. Turyshev on orbital data centers argues that feasibility is not determined by solar flux alone. A viable system has to close photovoltaic generation, eclipse energy storage, radiative heat rejection, communications, utilization, replacement cadence, and delivered compute-years over a finite mission life [6].
For a representative 1 MW high-sunlight orbital compute anchor, the paper estimates about 5,640 square meters of photovoltaic area and 2,500 square meters of radiator area, with fixed spacecraft mass raising the total to roughly 34 to 59 kg per delivered kilowatt [6]. At those mass levels, the combined launch and spacecraft-build cost would need to become extremely low to compete with terrestrial infrastructure [6].
That does not make orbital data centers impossible. It does suggest the first useful markets may be narrower: space-native preprocessing, Earth-observation triage, relay-integrated edge compute, defense or civil mission processing, and workloads where reducing downlink volume is more important than competing with terrestrial cloud on raw cost.
Another 2026 paper took that workload-first view, arguing that semantic abstraction can dramatically reduce payload data volume before transmission. In one Earth-observation example, the author reports 99.7% to 99.99% payload reduction by converting raw imagery into compact semantic artifacts [7].
That is the kind of orbital computing that makes intuitive sense: process data near the sensor, send down the answer, and reduce pressure on spectrum and ground infrastructure.
The astronomy risk is manageable only if it is designed in
If orbital data centers proceed, mitigation should not be an afterthought. The requirements should be explicit before launch.
At minimum, operators and regulators should be asking for:
- Optical brightness budgets: predicted and measured brightness across mission phases, including deployment, nominal operations, safe mode, and deorbit.
- Attitude and reflection planning: operational modes that reduce glints and avoid worst-case reflections over major observatories when possible.
- Radio-emission characterization: prelaunch and on-orbit measurement of intended and unintended emissions, including low-frequency bands relevant to radio astronomy.
- Public ephemerides: accurate, timely orbital data so observatories can plan around satellite passes.
- Observation-aware operations: automated coordination tools that allow satellites to reduce or reshape transmissions near sensitive telescope pointings when practical.
- End-of-life discipline: credible disposal plans, because failed data-center satellites could become large debris objects and long-lived optical/radio interference sources.
Some of this is already being explored in adjacent contexts. A 2025 paper on an Operational Data Sharing system describes a self-reporting approach that helps radio telescopes and adaptive satellite constellations coexist. The authors report preliminary experiments between NRAO and SpaceX Starlink teams that reduced downlink radio-frequency interference using telescope boresight avoidance techniques [8].
That is a useful model: not “astronomy versus satellites,” but operational coordination between systems sharing the same environment.
Regulation is lagging the architecture
The uncomfortable part is that orbital data centers combine several regulatory problems at once.
They are satellites, so they raise licensing, debris, spectrum, and conjunction-management questions. They are compute infrastructure, so they raise data, cybersecurity, export-control, and customer-assurance questions. They are high-power electrical systems in orbit, so they raise optical and radio-interference questions that do not fit neatly into legacy communications categories.
The IAU’s 2024 paper argues that mitigation of impacts on astronomical activities remains insufficiently regulated [4]. The Starlink radio-emission study highlights a related issue: unintended electromagnetic radiation can fall outside the normal regulatory frame for intentional transmissions [5].
That gap matters for orbital data centers because compute hardware is not a radio payload in the traditional sense, but it can still create radio-frequency consequences. If regulators only review the planned communications links and ignore the rest of the electrical system, they may miss the interference mode that radio astronomers actually see.
The same logic applies optically. A satellite’s communications function may be benign while its physical geometry still creates problematic brightness or glints.
The STC read
Orbital data centers are not automatically a bad idea. Space-native compute could reduce data bottlenecks, support Earth-observation missions, enable faster response for defense and disaster monitoring, and eventually support larger cislunar or deep-space systems.
But the phrase “data center in space” hides a lot of physical reality. A data center is not just compute. It is power, cooling, communications, maintenance, replacement, waste heat, and failure modes. Put that system in orbit and it also becomes part of the night sky, part of the radio environment, and part of the debris-risk landscape.
That is why astronomers should be treated as infrastructure stakeholders, not late-stage objectors.
The sky is not empty space waiting for business plans. It is an observing platform, a cultural resource, a scientific instrument, and an operational commons. Orbital data centers may still earn a place there. But they should have to prove, before they scale, that they can compute without making the universe harder to observe.
Sources
- SpaceNews, “Astronomers fear orbital data centers will interfere with observations,” June 2026. https://spacenews.com/astronomers-fear-orbital-data-centers-will-interfere-with-observations/
- Tom’s Hardware, “Elon Musk’s first-gen orbital data center craft spans wider than a Boeing 747 and runs an interchangeable chip payload,” June 2026. https://www.tomshardware.com/tech-industry/spacex-details-its-ai1-compute-satellite
- Tom’s Hardware, “SpaceX unveils 11-million-square-foot Gigasat factory, a new manufacturing facility for space-based data centers,” June 2026. https://www.tomshardware.com/tech-industry/big-tech/spacex-unveils-11-million-square-foot-gigasat-factory-a-new-manufacturing-facility-for-space-based-data-centers-aims-for-1-gw-year-of-space-ai-compute-by-late-2027-from-its-satellites
- IAU Centre for the Protection of the Dark, Quiet Sky from Satellite Constellation Interference et al., “Call to Protect the Dark and Quiet Sky from Harmful Interference by Satellite Constellations,” arXiv, December 11, 2024. https://arxiv.org/abs/2412.08244
- F. Di Vruno et al., “Unintended electromagnetic radiation from Starlink satellites detected with LOFAR between 110 and 188 MHz,” arXiv, July 5, 2023. https://arxiv.org/abs/2307.02316
- Slava G. Turyshev, “Orbital Data Centers: Spacecraft Constraints and Economic Viability,” arXiv, April 29, 2026. https://arxiv.org/abs/2604.27197
- Durgendra Narayan Singh, “Which Workloads Belong in Orbit? A Workload-First Framework for Orbital Data Centers Using Semantic Abstraction,” arXiv, March 19, 2026. https://arxiv.org/abs/2603.20317
- Bang D. Nhan et al., “ODS: A self-reporting system for radio telescopes to coexist with adaptive satellite constellations,” arXiv, February 20, 2025. https://arxiv.org/abs/2502.15068
Internal link suggestions
- Space debris and traffic management analysis for orbital-environment context.
- Space-based GPS jamming analysis for the broader radio-frequency operating environment.
- Long March 12B cadence analysis for large-constellation deployment context.
