Data Centers in Space: Power, Cooling & Launch Calculator

The 1 GW starting example

This table describes the starting settings. The live results in the calculator change when you move the controls. The example uses 65% sunlight, a 35-minute eclipse and a 50 °C radiator with two equally effective emitting faces.

A gigawatt is a rate of electricity use, not a measure of computing speed. Here it means 1,000 megawatts at the IT equipment. Auxiliary equipment adds another 150 MW. Battery losses average about 44.7 MW over the orbit. Radiator sizing uses the larger loss during charging or discharge: about 60.5 MW in this case. The heat to reject in that phase is about 1,210.5 MW.

How much solar-panel area is needed?

Near Earth, sunlight delivers about 1,361 watts per square meter to a surface facing the Sun. That is a rounded NASA solar-irradiance reference, not the electricity a panel delivers.

The example converts 30% of that sunlight to electricity, then applies an 80% output factor for effects such as temperature, pointing, aging and collection losses. This gives 326.64 W/m² while sunlit. NASA's spacecraft power reference discusses space cells and complete power systems; it does not establish the chosen output factor or the mass of this gigawatt array.

Are solar panels more efficient in space?

Space gives solar panels stronger sunlight without clouds or atmospheric absorption. But more light is not the same as higher cell efficiency. The 1,361 W/m² space reference is 36.1% above the 1,000 W/m² used in terrestrial solar-panel rating tests. The latter is a test condition, not Earth's average sunlight or a yearly energy yield. Those tests also specify 25 °C cell temperature and a terrestrial sunlight spectrum.

Many spacecraft use specialized multijunction cells with about 30% nominal conversion efficiency. That is a choice of cell technology, not an automatic gain from moving an ordinary panel into orbit. Sunlit panels can get hot, and radiation damage reduces their output with age. Use efficiency appropriate to the space sunlight spectrum, then allow for temperature, pointing, cell coverage, wiring and aging in the output-retained setting.

The calculator includes stronger sunlight, selected cell efficiency and time in sunlight separately. At the starting 65% sunlit fraction, the spacecraft collects sunlight for an average 15.6 hours per 24 hours, spread across its orbits. There are no modeled cloud losses. A favorable 100%-sunlight case reduces solar area from 7.034 to 4.401 km² with the other assumptions unchanged. It requires an appropriate orbit and pointing plan; space alone does not guarantee it.

The arrays must power the computers and refill the batteries during the sunlit part of the orbit. Only the energy sent through storage incurs the full battery round-trip loss. With 65% sunlight and 90% round-trip efficiency, the example needs about 1.838 GW of useful generation while sunlit. Its 25% solar capacity allowance increases the installed figure to about 2.298 GW.

Sunlit generation: P_sun = P_load × [f + (1 − f) ÷ η_rt] ÷ f

Solar area: A_solar = P_sun × (1 + margin) ÷ (S × efficiency × output factor)

Here, f is the fraction of time in sunlight, η_rt is battery round-trip efficiency and S is solar irradiance. Use watts and W/m² to obtain area in m². An unused generation allowance is spare capacity; it is not automatically extra heat in the computer cooling loop. Heat absorbed by the solar panels themselves needs its own thermal design.

What happens in Earth's shadow?

The example's 65% sunlight and 35-minute eclipse imply a 100-minute cycle. During the eclipse, supplying 1.15 GW for 35 minutes takes 670.833 MWh of delivered energy. The battery must store more because it cannot be fully drained and discharge is not lossless.

Nominal stored energy: E = P_load × eclipse hours ÷ (allowed discharge × discharge efficiency)

That gives 882.675 MWh. At the assumed 150 Wh/kg for a complete pack, the battery mass is about 5,885 tonnes. This energy density is a pack-level scenario informed by NASA's battery examples. Cell-only figures exclude some packaging and protection. Capacity fade, reserve energy and failures still need separate allowances; the calculator does not prove a battery service life.

Changing to 100% sunlight is a favorable comparison. The calculator then removes scheduled eclipse storage. A real orbit and pointing plan must support that condition through the mission. Sun-synchronous orbit alone does not guarantee uninterrupted sunlight, and avoiding routine eclipses does not remove every need for backup power.

How does an orbital data center lose heat?

Almost all electricity used by the onboard equipment ends up as heat. There is no surrounding air to carry it away. Heat must travel from the equipment to outside surfaces and leave as infrared radiation. Those surfaces also absorb heat from the Sun, Earth and nearby hardware. NASA's thermal-control reference explains this balance.

A sealed liquid loop can work in vacuum. Cold plates collect heat, a pump moves the coolant and radiator panels release it. The liquid stays inside pressurized pipes. The loop must be designed for leaks, freezing, pressure and space conditions.

The radiator calculation uses a simplified radiation balance:

Net cooling per emitting face: q_net = ε × σ × T⁴ × U − H

Physical panel area: A_panel = Q ÷ (number of useful faces × q_net)

T is the radiator surface temperature in kelvin: °C + 273.15. ε is its ability to emit infrared heat. σ is the Stefan–Boltzmann constant. U is the assumed effective exposure factor, and H is already-absorbed environmental heating in W/m². Q is the heat that reaches the radiator system. The tiny cold-sky background term is neglected at these temperatures.

At 50 °C, ε = 0.9, U = 0.8 and H = 30 W/m², each modeled face sheds about 415.2 W/m² net. The 1,210.5 MW heat load therefore needs 2.915 km² of emitting surface. Two useful faces reduce the panel footprint to 1.458 km².

Both faces must actually work. Earth, solar arrays or neighboring satellites can heat or block a face. The chosen exposure and heating values are favorable assumptions, not a solved orbital layout. Radiator sizing adds the larger steady battery loss during charging or discharge. At the default settings, charging adds about 36.2 MW and discharge adds about 60.5 MW, so the eclipse phase sets the area. Rapid load changes, start-up, battery temperature limits, separate circuits and equipment failures still need further analysis.

Charging efficiency: η_charge = η_rt ÷ η_discharge.

Discharge loss: L_discharge = P_load × (1 ÷ η_discharge − 1).

Charging loss: L_charge = P_load × (1 − f) ÷ (f × η_discharge) × (1 ÷ η_charge − 1).

Radiator heat: Q = P_load + the larger of L_charge and L_discharge. Each phase is treated as steady, with constant load. In the 100% sunlight case these scheduled battery losses are zero.

Radiator temperature is not GPU temperature

A hotter radiator can reject more heat from the same area. But ordinary heat flow needs a temperature drop from the chip, through its cold plate and coolant, to the radiator. A GPU's maximum chip temperature does not mean the whole radiator can run at that temperature. Thermal resistance and local coolant temperatures matter.

The complete servers used for the mass comparison are terrestrial products. Their airflow and operating conditions do not make them ready for vacuum. Choosing a 50 °C radiator here describes a hypothetical compatible cooling system, not a modification approved by the server manufacturer.

Other ways to move and reject the heat

The cooling selector compares four heat-transport ideas. At the same surface temperature and surroundings, each still needs enough radiator area to reject its heat.

• Pumped liquid: A pump circulates fluid through cold plates and radiators. This is the starting case.
• Heat pipes: A sealed working fluid evaporates at a warm end, condenses at a cooler end and returns through a wick or similar structure. NASA describes heat pipes and loop heat pipes used for spacecraft. They move heat; they do not make a hotter rejection surface possible without added work.
• Pumped two-phase loop: A pump circulates fluid that changes between liquid and vapor. The phase change carries heat, which must still leave through radiators. NASA's two-phase loop project also describes flow-distribution challenges.
• Heat pump: A refrigeration cycle uses electricity to move heat to a hotter radiator. ESA has studied this approach. A smaller hot radiator must be weighed against added electrical demand and equipment.

The heat-pump setting uses cooling COP: heat removed from the cold side divided by electrical work. It assumes the base load is on the cold side. At COP 3, removing 1,150 MW needs another 383.3 MW of electricity. That work also becomes heat. Keeping the radiator at 50 °C therefore increases its area; the possible benefit comes from a compatible higher rejection temperature.

The calculator does not model the cold-side temperature, so it cannot confirm that a chosen COP and radiator temperature work together. Each method uses the same selected thermal-hardware mass allowance per kilowatt. Change that allowance when you have a specific design; the selector does not assume that one method is lighter.

Other approaches include lowering the computing load, improving chip efficiency, spreading heat through conductive structures, or briefly storing heat in a phase-change material. Storage delays heat rejection rather than removing it. Venting a hot fluid can carry energy away, but consumes material and needs a separate mass and lifetime calculation. These options are not sized here.

What is included in the mass?

The computer reference is a complete NVIDIA DGX B200 system: eight GPUs, 14.3 kW maximum input and 142.4 kg maximum system mass. Dividing 1 GW by 14.3 kW and rounding up gives 69,931 server units. Multiplying by eight gives 559,448 GPUs. This is a hardware count, not a claim about training speed or usable AI throughput.

Only the server specifications above describe a particular manufactured product. The mass coefficients are editable planning assumptions. Array and radiator coefficients are intended for assemblies, including their local support and deployment parts. The heat-transport allowance is for equipment beyond radiator hardware already counted. The computer allowance covers additional mounting and adaptation; it does not prove that the server can survive launch or radiation.

A real design must account for structure, wiring, communications, control electronics, pumps, coolant, shielding, propulsion, propellant and deployment hardware. Some are represented only by broad allowances here. The model has no separate propulsion, disposal or spacecraft-structure design. Its 20% mass allowance cannot confirm that every missing item will fit. Battery protection and cooling must also be included in a chosen pack specification or added separately.

A DGX H100/H200 reference offers another comparison: eight GPUs, 10.2 kW and 130.45 kg per complete system. Different processors change the equipment count and mass per kilowatt. They also change performance, which this calculator does not estimate.

Mass, folded volume and launch cost

A rocket can reach its weight limit before its cargo space is full, or run out of room first. The calculator checks both. It uses the folded transport volume of arrays and radiators, not their deployed area.

Mass trips: round up(total launch mass ÷ available mass per trip).

Volume trips: round up(total folded volume ÷ usable volume per trip).

Aggregate lower bound: take the larger count.

The starting case assumes 15 tonnes per trip and a 145 m³ cargo-volume allowance, of which 70% is used. That leaves 101.5 m³ per trip. Neither the volume nor the payload is a provider promise for this orbit. The SpaceX Falcon User's Guide requires payloads to meet envelope, adapter, center-of-gravity and launch-load constraints.

The folding assumptions are 0.01 m³ per m² of solar array and 0.02 m³ per m² of radiator. Packing densities are 250 kg/m³ for computers, 400 kg/m³ for batteries and 200 kg/m³ for other equipment. The model also assigns volume to the added mass allowance at 200 kg/m³. These choices give about 256,625 m³ in total: 2,529 volume trips versus 5,111 mass trips.

Taking the larger number is only an aggregate check. It does not show that individual modules fit inside a fairing or can share a flight. Adapters, module shape, deployment sequence, launch inclination, orbital planes and spare launches can all increase the count. It also does not estimate launch cadence or completion time.

The $74 million budget input is informed by SpaceX's published 2026 Falcon 9 price reference. Its Capabilities & Services sheet distinguishes its standard priced service from maximum fully expendable performance. The calculator's 15-tonne/$74-million combination is an illustration, not a quotation. Do not combine a rocket's maximum expendable payload with a reusable price and assume that is a purchasable mission.

Launch budget = aggregate trip count × assumed price per trip. The starting result is $378.214 billion. This covers launch services only. It excludes hardware purchases, manufacturing, qualification tests, assembly, ground facilities, communication systems, insurance, operations, repair, replacement and disposal. It is not a total project cost or a comparison of lifetime computing costs on Earth and in orbit.

A network of smaller satellites

The drawing and area squares help you compare scale. They do not require one rigid platform several kilometers wide. For example, an assumed 1,000 modules with 1 MW of IT input each would total 1 GW. Google's Project Suncatcher research explores connected compute satellites, illustrating why a network is an important architecture to consider.

Splitting the load changes the engineering problem. Each module needs power and thermal control, while communication links must carry data between modules and back to Earth. A distant satellite cannot necessarily share another satellite's spare power or cooling capacity.

What else would engineers need to solve?

• Radiation can damage electronics or change stored data. Tested components, shielding, error-correcting memory and spare computing capacity can help. Adding a kilogram allowance does not prove radiation tolerance.
• A tiny impact can puncture a coolant line. Separating loops, isolating leaks and carrying spare capacity can stop one failure from shutting down the whole network.
• The data must get to and from orbit. Optical links offer high data rates, but require accurate pointing. Ground stations, weather, radio links and the workload determine useful bandwidth and delay.
• Large panels must unfold and stay pointed correctly. Modular structures, deployment tests and attitude-control systems add weight and complexity. Solar arrays want sunlight; radiators need to limit unwanted heating.
• Hardware wears out. Solar output, battery capacity and radiator coatings change with age. Replacements must be launched, and failed spacecraft need a disposal plan.

The orbit also affects drag, eclipse duration, radiation exposure and collision avoidance. Large panels add deployment, pointing and structural challenges. Repairing failed electronics and replacing outdated processors is harder than visiting a building on Earth. The U.S. GAO's assessment of data centers in space discusses thermal, economic and satellite-management barriers.

Use the results to compare assumptions and find the largest demands. Turning them into an operating system requires a consistent orbit, module layout, thermal network, power design, communication plan and end-of-life plan.

Space data center questions

Sources and assumptions

The physical references are NASA's near-Earth solar irradiance, the Stefan–Boltzmann radiation law, and spacecraft power and thermal-control guidance. The complete-server reference comes from NVIDIA. Launch constraints come from SpaceX. The links beside each explanation lead to those primary sources.

The example's orbit, output factors, radiator exposure, environmental heating, mass per area, battery use, subsystem allowances, packing and launch budget are scenario inputs. They let you explore the scale of the problem. They are not a jointly verified mission design. Source and project information was checked on November 3, 2026.