Google just announced Project Suncatcher, their version of a solution to achieving space data centers using a satellite constellation. While I intended to write a different post for today’s Inkhaven, I got sidetracked so will post some early comments on this paper instead.

Google’s mission concept

Google’s concept is for an 81-satellite cluster where each satellite has roughly 28 kW of solar power (using the specs of a Starlink v2), which totals to 2.26 MW for the demo cluster. They mention scaling to “terawatts” eventually but provide no specifics. The satellites are in formation flight—separated by 100-200m spacing in a 1 km cluster radius—in dawn-dusk sun-synchronous orbit at 650 km.

By focusing on a modular design of smaller, interconnected satellites, their proposal sounds to me more plausible than the Starcloud solution of one ginormous monolithic structure. Google’s approach, if it worked, would be a more easily scalable challenge without the issues of Starcloud’s concept; aside from its obvious challenges with radiator sizing (or developing newer heat dissipation technologies), the startup also needs to tackle challenges of robotically assembling the largest orbital structure ever made (if it were gets there) and then maintaining it. This will be massive because orbital debris in sun synchronous orbits aren’t exactly negligible. Ensuring either of these concepts don’t become a part of the debris problem (or worse) is also a major concern.

Google states that their concept’s foundational challenges are in:

1. high-bandwidth communication between satellites (i.e., inter-satellite links)
2. relative orbital dynamics, where they present some initial results using Clohessy-Hill-Wiltshire dynamics; and
3. radiation-hardened compute.

Starcloud comparison

I was especially interested in seeing if they had a mission architecture laid out or launch/mass analysis. Comments on how it stacks up against Starcloud’s 40 MW concept would have been nice too; it is something I previously analysed using the ISS as a benchmark. However, all we get from Google is the following qualitative statements about their conceptual differences:

Proposals exist for ‘monolithic’ data centers in space where individual spacecraft significantly exceed the size of any current or planned launch vehicle. While such design concepts reduce the need for high-performance inter-satellite links, they involve new challenges: such structures would have to be assembled in space by humans or robots; collision avoidance would be more cumbersome; and structural requirements would add mass and complexity. Our proposed approach would instead rely on arrays of smaller satellites.

Launch

1. Launch numbers: For the reference mission, if one assumes Starlink v2-like satellites weigh 575 kg each, that’s 47 tons in total; this could easily fit in a single Starship. But to rival Starcloud’s 40 MW concept, Google also require nearly 9 launches of a 100-ton Starship for its 1434 satellites. This halves to 5 if Starship’s payload-to-orbit doubles to 200 tons. However, this assumes the 575 kg Starlink mass includes adequate radiators for TPU heat dissipation. Starlink’s existing radiators handle ~1-2 kW; TPU satellites generating 10-28 kW of heat would require proportionally more radiator mass, potentially doubling or tripling the satellite mass.
2. Launch costs: At $200/kg launch that Google estimates by 2035:
   • Google’s 825 tonnes (using Starlink v2 satellites mass only): $165M
   • If these TPU satellites require more radiators for the full 28 kW thermal load, then assuming ISS radiator mass density (15 kg/m²) could add ~660 kg per satellite, bringing total mass to ~1,775 tonnes and cost to ~$355M. This should be treated as an upper bound estimate as ISS technology is dated; more comments on this aspect in the following section.
   • Starcloud’s 40 MW system (from my previous analysis): $340M-$480M

Without knowing Google’s radiator requirements, a direct cost comparison is premature. If we naively assume 575 kg satellites are adequate, Google’s system would cost as little as $165M. Starlink is optimised for comms, not compute, and we don’t know if its thermal system scales to TPU loads.

Limitations: heat dissipations as usual

One reason that I worked with the ISS as a benchmark for the Starcloud analysis was that they’re both large monolithic structures, which, in theory, might have similar radiator technologies. To my knowledge there are really no novel radiator technologies currently for such large space structures.

This could work differently for google’s constellation but Google offers scant commentary on the matter. All we get are vague sounding statements such as the below:

Cooling would be achieved through a thermal system of heat pipes and radiators while operating at nominal temperatures.

Effective thermal management is a critical optimization challenge for power-dense TPUs operating in a vacuum. Advanced thermal interface materials and heat transport mechanisms, preferably passive to maximize reliability, are essential to efficiently move large heat loads from the chips to dedicated radiator surfaces.

Future space-based experimental milestones should also involve solutions for thermal management, high-bandwidth ground communications, and on-orbit reliability and repair strategies.

They acknowledge thermal management is a “critical challenge” and mention heat pipes and radiators, but they never quantify:

• Required radiator surface area
• Radiator mass
• Mass per unit of heat rejection capacity
• How this affects total system mass or launch counts

While Google does compare power-to-mass ratios to estimate launched power price ($/kW/year) using Starlink data but don’t build on that to estimate any thermal rejection specs. Instead we get the following commentary on Starlink v2 mini:

Exact specifications have not been publicly released by SpaceX, but photometric and other analyses yield solar panel area ~105m².

I suspect they could have done a bit more analysis from there on heat rejection because all input power basically becomes heat. For this reason, I determined an upper bound using the inefficient ISS specs for radiators.

Their preprint paper is here in case someone else wants to take a stab at checking the math for me.