Beyond Project Natick: Why Commercial Subsea Compute Must Be Modular

← All Articles

When Microsoft concluded Phase 2 of Project Natick in 2020, the primary research questions had been answered. Servers can survive and operate reliably in a pressurized sealed vessel on the ocean floor. Failure rates were lower than in comparable terrestrial deployments. The cooling properties of cold seawater are real and measurable. Underwater compute is not science fiction.

Project Natick was research infrastructure. It was designed to answer whether underwater deployment was feasible, not to serve as a template for commercial data center operations. The distinction matters. A research program succeeds when it generates valid conclusions; a commercial infrastructure program succeeds only when it can scale, be maintained, be expanded, and survive multiple hardware generations. These are different problems with different solutions.

Seabase is developing shared subsea infrastructure designed from the beginning for commercial operation. The operating model differs from the sealed monolithic pod approach in ways that reflect the requirements of commercial infrastructure rather than the requirements of a research trial. This essay describes what Natick demonstrated, where the monolithic pod model hits operational limits, and the design logic behind a modular approach built around independently retrievable compute modules.

What Project Natick Demonstrated

Project Natick ran in two phases. Phase 1, conducted in 2015 off the coast of California, deployed a small single-rack vessel to test basic feasibility. Phase 2, conducted from 2018 to 2020 near the Orkney Islands in Scotland, deployed a larger vessel containing 864 servers and 27.6 petabytes of storage, connected to shore power and communications via submarine cable.

The Phase 2 results were substantive. The server failure rate in the subsea vessel was roughly one-eighth the rate observed in comparable terrestrial deployments over the same period. Microsoft researchers attributed this to the controlled, nitrogen-filled atmosphere inside the vessel: no corrosion from humidity, no vibration from human activity, no oxygen-driven oxidation. The thermal environment was stable and consistent in ways that terrestrial facilities with variable ambient temperatures cannot match.

The Orkney deployment was also powered entirely by renewable energy sources available in that region: wind, wave, and tidal generation. This was specific to the Orkney site and the research context, but it demonstrated that subsea deployment need not carry a high-carbon energy profile when sited appropriately.

None of this means the sealed-pod, single-deployment architecture that Project Natick used is the right model for commercial operations. Natick's conclusions apply to the feasibility and environmental properties of underwater operation. They do not constitute a commercial operating model.

The Monolithic Subsea Model and Its Limits

A monolithic subsea pod is, in concept, a complete data center placed underwater as a single unit. Servers, storage, networking, cooling, and power distribution are sealed together in a vessel that is then deployed and connected to shore via cable. The vessel is designed to operate for its intended service life, then be retrieved.

This model is well-suited to specific use cases. A temporary deployment for a defined project duration, where the full payload is known in advance and hardware refresh during the deployment period is not required, fits the sealed monolithic approach. Remote or harsh environments where surface access is difficult favor self-contained deployment.

Commercial data center infrastructure, however, does not work this way. Commercial facilities are expected to operate across multiple hardware generations, grow capacity incrementally as demand justifies it, respond to individual hardware failures through component-level replacement rather than full vessel retrieval, and adapt to changes in workload profiles over time. These requirements impose constraints that the sealed monolithic model handles poorly.

If a single server in a sealed pod develops a fault that prevents it from operating, the operator faces a choice between tolerating the degraded capacity until the next retrieval window or retrieving the entire vessel to address one failed node. Neither option is operationally acceptable for infrastructure supporting persistent customer workloads. The sealed monolithic model treats the vessel as the unit of management; commercial operations require the ability to manage at finer granularity.

Hardware refresh creates a similar problem. GPU generations advance on a cadence of two to four years. A sealed pod with a fixed hardware payload becomes progressively less competitive as newer accelerators are released. Retrieving the entire vessel to upgrade a subset of the compute, then redeploying, is operationally expensive. For commercial infrastructure, this cost would be prohibitive across a large deployment.

Separating Infrastructure from Compute

The core architectural distinction in the Seabase approach is the separation of the subsea foundation from the compute modules that occupy it. The foundation, including structural support, power distribution, cooling management, and communications infrastructure, is designed as a long-lived installation. The compute modules that attach to the foundation are designed to be individually retrievable.

This separation addresses the operational problems inherent in the monolithic model. The foundation, once in place, does not need to be retrieved to address changes in compute hardware. Individual modules can be brought to the surface for service, repair, or replacement while the remaining modules continue operating. New modules with different hardware specifications can be added to an existing foundation as demand grows or as new hardware generations become available.

The distinction mirrors the logic of surface-level data center design. In a terrestrial facility, the building, power distribution, and cooling infrastructure are long-lived assets expected to outlast multiple generations of server hardware. Individual racks, servers, and drives are managed independently of the facility structure. Seabase's approach applies the same separation of concerns to subsea deployment.

A monolithic pod is a complete data center placed underwater. Seabase is developing shared subsea infrastructure that supports a changing fleet of independently retrievable compute modules.

This is not merely an architectural preference. It reflects the economic reality of commercial infrastructure: the foundation investment is recovered over a multi-decade service life, while compute hardware is refreshed on a much shorter cycle. Conflating the two into a single sealed unit forces every hardware decision to carry the full weight of a deployment event.

Serviceability from the Beginning

Serviceability is often treated as a feature added to an existing design. In subsea infrastructure, serviceability must be a primary design constraint from the outset, because the cost of adding it after the fact is far higher than in terrestrial contexts.

A terrestrial server can be replaced by a technician in minutes. An unsealed subsea module must be retrieved, serviced, and redeployed through a defined operational procedure. The effort involved is greater, which means the design must minimize how often retrieval is required, make retrieval straightforward when it is required, and ensure that retrieving one module does not require disturbing adjacent modules.

Seabase's infrastructure design incorporates retrieval as an expected operational procedure rather than an exceptional event. Module interfaces are designed for repeated attachment and detachment. Power, cooling, and communications connections are intended to be made and broken through defined mechanical operations. The foundation is designed to remain in place and operational while individual modules are absent.

This design approach changes the economics of subsea operation in important ways. When retrieval is operationally straightforward, the operator is no longer forced to choose between tolerating failed hardware and absorbing a large operational cost. Routine hardware refresh becomes feasible. Warranty service, firmware updates that require physical access, and module-level testing can all be conducted on retrieved modules at surface facilities.

Isolating Failures to Their Origin

Any sufficiently large compute deployment will experience hardware failures. The rate and character of failures depends on hardware quality, the operating environment, and the degree of redundancy in the system. Natick's research suggested that the subsea environment itself is favorable for hardware reliability. But favorable does not mean failure-free, and commercial infrastructure must be designed for failure isolation.

In a modular architecture, a failure in one compute module does not propagate to adjacent modules on the same foundation. Power distribution is designed such that a fault in one module's power path does not affect the module's neighbors. Communications and cooling infrastructure is designed with similar isolation. The module boundary is also an operational boundary: problems are identified, attributed, and resolved at the module level rather than at the level of the entire deployment.

This isolation has direct consequences for customer operations. A customer with reserved capacity across multiple modules on a foundation should not see their workloads disrupted by a failure in a module they do not occupy. The modular boundary enforces this isolation at the infrastructure level rather than relying on software-layer isolation alone.

Failure isolation also simplifies root cause analysis. When a single module is retrieved for service, examination of its hardware provides clear information about the nature and origin of the failure. In a sealed monolithic pod, the interactions among many components in a shared environment make attribution more complex.

Expanding Capacity in Stages

Commercial infrastructure rarely justifies full build-out before any customer workloads are operational. The economics of data center construction, terrestrial and subsea alike, generally favor staged expansion: initial deployment sufficient to serve early demand, with additional capacity added as demand grows and as the deployment proves itself operationally.

The modular approach supports staged expansion directly. A foundation designed for a target capacity can be partially populated at initial deployment, with additional modules added as demand justifies. Each module addition is an incremental investment tied to incremental demand rather than a large upfront commitment to capacity that may not be needed for years.

Staged expansion also reduces risk. A smaller initial deployment can validate operational procedures, confirm connectivity and power performance, and establish the relationship between the subsea infrastructure and the shore-side systems before committing the full capital expenditure of a large deployment. Problems identified during initial operation can be addressed before they affect a larger number of modules.

The ability to expand in stages is also relevant to regional AI capacity planning. Organizations planning to deploy persistent AI workloads in a given region may not know their full capacity requirements at the time of initial deployment. Staged expansion allows capacity to grow with actual demand rather than requiring a forecast of peak demand before any infrastructure is operational.

Supporting Multiple Hardware Generations

The history of data center hardware is a history of rapid generational change. GPU architectures that were state-of-the-art two years ago are now a generation behind in inference performance per watt. Storage density has increased dramatically. Networking speeds have advanced through multiple generations within the operational life of a single building. Commercial infrastructure must accommodate this pace of change.

A sealed monolithic pod is hardware-generation locked. The servers deployed in the vessel at time of installation are the servers that operate until the vessel is retrieved. If a new GPU generation offers two times the inference throughput per watt, the only way to benefit from that improvement within a sealed deployment is to retrieve the vessel and redeploy it with new hardware. The foundation investment is fully retrieved; nothing carries over.

The modular approach handles hardware generations differently. Modules containing older hardware can be retrieved and replaced with modules containing newer hardware on the same foundation. The foundation itself, the long-lived component, continues to provide power, cooling, and communications to whatever generation of compute modules occupies it. The customer experience is of continuous infrastructure with improving hardware rather than periodic full replacements.

Supporting multiple hardware generations simultaneously is also possible in the modular architecture. A foundation might carry modules with different accelerator types suited to different workloads: some modules optimized for high-throughput batch inference, others suited to latency-sensitive applications, others to memory-intensive workloads. The foundation is hardware-agnostic within the constraints of its power and cooling specifications; the module defines the hardware profile.

For customers, this means that a capacity reservation does not need to specify hardware that is expected to remain competitive for the full term of the reservation. Infrastructure can refresh the hardware layer within an ongoing commercial relationship rather than requiring new procurement cycles tied to vessel replacement.

A Platform Rather Than a Pod

The distinction between a pod and a platform reflects a difference in how infrastructure is conceptualized over time. A pod is a thing you deploy; a platform is something you build on. A pod has a fixed contents and a service life; a platform accommodates change.

Seabase is developing subsea infrastructure as a platform. The physical foundation is the long-lived layer; the compute modules are the variable layer. The shore-side systems, including the control plane that customers use to manage their deployments, connect to a logical model of capacity that persists across hardware generations rather than being tied to specific physical modules.

This platform perspective also changes how the subsea environment is understood. In the pod model, the ocean is the context in which a sealed vessel happens to operate. In the platform model, the ocean is a thermal and geographic resource: cold water for cooling, coastal location for network proximity, near-shore depth for operational access. The infrastructure design takes explicit advantage of these properties rather than treating them as incidental to a deployment decision made for other reasons.

Geography matters to this model. The network location of subsea infrastructure positioned near submarine cable landing stations, IX infrastructure, and major coastal population centers is a durable advantage that benefits every generation of hardware deployed on the same foundation. The geographic investment compounds over time in a way that a temporary monolithic deployment cannot.

The platform model also implies different relationships with customers. A customer occupying modules on a persistent foundation has a long-duration relationship with the infrastructure, not a lease on a sealed vessel with a defined end date. The infrastructure relationship resembles a terrestrial colocation or reserved-capacity engagement more than it resembles chartering a vessel for a defined term.

For organizations evaluating subsea AI infrastructure, the relevant questions are not simply whether underwater operation is feasible. Natick settled that. The relevant questions are whether the infrastructure can grow with demand, whether hardware can be refreshed without full redeployment, whether failures can be isolated and addressed without disrupting the entire deployment, and whether the operator relationship is built for continuity. These are the questions the modular platform model is designed to answer.

For how modular subsea platforms compare with floating surface facilities against Seabase's coastal operating goals, see Floating vs. Subsea Data Centers. For a neutral map of ocean-compute approaches, see the ocean compute company landscape. For environmental accountability and community footprint context, see Environmental Accountability for Subsea AI Infrastructure and Reducing the Physical Footprint of AI Infrastructure. To discuss subsea infrastructure options, reserved capacity, or regional deployment requirements, contact Seabase.