I. The hum of modern data centers 
In Ashburn, Virginia, a row of servers draws 40 megawatts from the grid and exhales it as heat. Chilled water circulates through copper pipes at 2,800 liters per minute to carry that heat away. Outside, cooling towers the height of apartment buildings return it to the atmosphere. Ashburn now consumes more electricity than some nations. The machines inside process queries. They store application state.
This is a data center and there are thousands like it. They account for 4.4 percent of the electricity consumed in the United States, a figure that will double before the end of the decade. Concerns about their environmental impact and energy costs led New York to pass a one-year ban on the construction of new hyperscaler data centers in July 2026. 14 other states have also introduced bills to restrict new data center construction.
II. Why are companies planning data centers in space?
In January 2026, SpaceX filed an application with the Federal Communications Commission for one million satellites. These are not communication satellites, but data centers. At the World Economic Forum in Davos, Elon Musk stated that the lowest-cost location for AI computation would be in space within two to three years.
Separately, a company called Starcloud filed for 88,000 satellites of its own. Starcloud had already placed a single Nvidia H100 GPU into low Earth orbit and run a Gemini inference workload on it. The chip functioned and the workload completed.
The combined investment required to deploy these constellations exceeds one trillion dollars. The economics rest on three substitutions:
Solar power replaces grid electricity, and in orbit it is five to seven times more productive than on the surface. No atmosphere absorbs it. No clouds block it.
Radiator panels replace cooling water. Heat leaves the satellite by emission into the cosmic microwave background at 2.7 Kelvin, the residual temperature of the universe itself. The reservoir is free. The panels are not. Vacuum is also an excellent insulator, and a 700-watt chip must shed every joule through radiation alone, into a sky that contains the Earth and, half the time, the Sun.
Lastly, open orbit replaces land and zoning. While several U.S. states are currently considering legislation to pause terrestrial data center construction, there are no neighbors in orbit to object. Well, none that we know of!
Until now, most discussion of orbital infrastructure has focused on compute: how to power GPUs, cool them, and connect them across space. However, every stateful application also depends on a database. If space-based computing becomes practical, distributed databases will face an entirely new operating environment: one where latency, topology, failure domains, and even jurisdiction are constantly in motion. This article explores what those challenges might look like, and why some of the architectural principles developed for terrestrial distributed systems may prove unexpectedly relevant beyond Earth.
III. What happens when databases move to space?
Moving databases into space introduces a different set of engineering challenges than moving compute. While most of the orbital computing conversation is about GPUs, inference, training runs, and floating-point operations per second per dollar per kilowatt, every stateful application ultimately depends on a distributed database to persist state, coordinate work, and maintain consistency. These are important quantities, and the engineers working on them are solving genuinely difficult problems in thermal management, power delivery, and radiation hardening.
Compute is stateless, however. A GPU performs a matrix multiplication, returns a result, and retains nothing. It has no memory of the previous calculation and no obligation to the next one. Every application that persists data, coordinates work, or maintains a record of what has happened requires a database to store that information. A database must survive node failure, tolerate network partitions, and maintain consistency across replicas that may disagree about the order of events.
One million satellites will run computations. Some of those computations will need to remember their results. Where does that memory live and how will it be managed?
That question shifts the conversation from orbital compute to orbital data infrastructure. Solving one without the other would leave many real-world applications incomplete.
IV. How do distributed databases already solve part of the problem?
CockroachDB was designed for a scenario that, at the time of its creation, was entirely terrestrial: a database distributed across multiple data centers, in multiple geographic regions around the world, that survives the loss of any node, any rack, or any entire data center without human intervention and without losing a single committed transaction.
One of the mechanisms that drives this behavior is a consensus protocol called Raft. Every write is proposed to a group of replicas. A majority must agree before the write is committed. If a replica fails to respond, whether because of a network partition, a hardware fault, or atmospheric reentry, the remaining replicas continue without it. No operator is paged. The system just handles it.
On the ground, this architecture protects against power outages, fiber cuts, and the occasional backhoe. The nodes sit in racks, the racks sit in buildings, and the buildings sit on foundations that don’tt move. In orbit, the foundations move at 7.66 kilometers per second and instead of backhoes or water leaks, there are meteor showers.
V. How would a distributed database work across a satellite constellation?
Consider a cluster of 300 CockroachDB nodes distributed across a constellation in low Earth orbit at 550 kilometers altitude. Each node is contained in a satellite, and each satellite communicates with its neighbors via optical laser links. The constellation is arranged in orbital planes, each plane containing several dozen satellites that trace the same ground track, offset by time. (An orbital plane is a flat surface that passes through the center of the Earth: The orbital plane contains the satellite's orbit, every orbit traces an ellipse, and that ellipse is contained within that single flat surface. It’s like sliding a cardboard sheet through the center of an orange.)
A CockroachDB cluster on the ground uses a concept called localities to describe its topology. A node might declare itself as --locality=region=us-east,zone=us-east-1a. The database uses this information to place data near the users who access it and to ensure that replicas are spread across failure domains. If us-east goes down, an application can use the data copies in us-west and eu-central.
An orbital node might declare itself as --locality=shell=leo-550,plane=47,position=12. The database would distribute replicas across planes, ensuring that no single orbital plane is a single point of failure. A micrometeorite strike that disables three satellites in Plane 47 does not affect replicas in Planes 23 and 68. A "shell" is a spherical surface at a given altitude, a soap bubble at a certain altitude above the Earth. Orbital planes intersect the Earth and the shells. The satellite travels across the shell where it intersects with the orbital plane.
This much is straightforward. CockroachDB already knows how to do this. The localities are strings. The replication logic is the same whether the string says us-east or plane-47.
The problems begin when the strings start to move.
Related
State of Resilience 2025: Confronting Outages, Downtime, and Enterprise Readiness — a 2025 report on operational resilience across 1,000 global enterprises and how distributed SQL combats costly downtime.
VI. Should data live in orbit or on Earth?
Whether data should live in orbit or on Earth depends on a tradeoff between autonomy and economics. Understanding that tradeoff starts with an important difference between compute and storage.
A GPU is an extraordinary value per kilogram. An Nvidia H100 weighs approximately 3 kilograms and, in a terrestrial data center, generates revenue measured in thousands of dollars per hour. At the current Falcon 9 launch cost of roughly $3,300 per kilogram, the launch expense is a rounding error against the card's lifetime earnings. The economics of space-based compute work because compute is dense in value per unit mass. Storage is not.
An enterprise NVMe SSD stores four terabytes in about 200 grams. The launch cost for the drive itself is trivial: less than a dollar per terabyte to put it in orbit. But the drive requires a satellite. The satellite requires a chassis, solar panels, thermal radiators, a laser communication terminal, and a station-keeping propulsion system. The total mass per node is measured in hundreds of kilograms. At $3,300 per kilogram, each satellite costs several hundred thousand dollars to launch before it stores a single byte.
And storage, unlike compute, does not earn its keep through activity. A GPU performs work. It multiplies matrices, runs inference, returns results. Its value is measured per hour. A disk holds state. It persists a row that was written once and may be read four times over the next year, or four million times. Its value is measured per year of durability, not per cycle of computation.
This creates a question that the compute-focused orbital industry has not yet confronted: Is it cheaper to store data in orbit or to transmit it to the ground?
The answer has implications beyond infrastructure costs. It affects how autonomous an orbital platform can become, how resilient it remains during network disruptions, and which categories of applications, from scientific research to defense to AI inference, can operate without depending on continuous connectivity to Earth.
The argument for orbital storage is autonomy. A database that keeps its state on the satellites can operate independently of ground stations. If the laser link to the surface is interrupted by weather, orbital mechanics, or geopolitics, the constellation continues serving queries from local replicas. The data is co-located with the compute, for low latency low and high availability.
The argument for ground storage is economics. Terrestrial storage costs approximately $20 per terabyte per year. Space-based storage, once satellite and launch costs are amortized, costs orders of magnitude more. A hybrid architecture that runs compute in orbit but persists durable state to ground stations would minimize the mass in orbit and the cost of the constellation.
However, a hybrid architecture reintroduces the very dependency that orbital computing was meant to eliminate. If the database is on the ground, every orbital query must wait for a round trip through the atmosphere. At 550 kilometers, that is 3.67 milliseconds each way. That may be acceptable for a single query. For a write that must be acknowledged before the next computation proceeds, it is a bottleneck that compounds with every dependent operation.
The likely answer is the same one that distributed databases have always given: It depends on the workload. Hot data that is frequently accessed and latency-sensitive, lives near the compute. Cold data that is archival, compliance-driven and infrequently read sinks to the cheapest storage available. On the ground, that means SSDs for hot data and object storage for cold. In orbit, it means satellite storage for hot data and ground stations for cold.
VII. How do latency and consensus change in orbit?
A signal traveling from a satellite at 550 kilometers altitude to a ground station directly below requires 1.83 milliseconds. The round trip takes 3.67 milliseconds. This is fast enough for most database operations. A Raft consensus round among three replicas on the same orbital plane, separated by a few hundred kilometers of laser link, might complete in under 5 milliseconds.
But not all replicas will be on the same plane. The entire purpose of distributing replicas across failure domains is that they are physically separated. A satellite in Plane 12 communicating with a satellite in Plane 47 on the opposite side of the constellation may need to route through five or six intermediate satellites, each adding its processing and propagation delay. A consensus round across the constellation could take 30 to 80 milliseconds.
On the ground, this would be unremarkable. A CockroachDB cluster spanning US-East and EU-West routinely completes consensus in 70 to 90 milliseconds. The database is designed for it.
In orbit, the latency is not constant: Since the satellites are moving, the routing topology changes with every orbit. A consensus round that takes 30 milliseconds at time T may take 65 milliseconds at time T plus twelve minutes, when the orbital geometry has shifted and the optimal laser path now transits through a different set of relay nodes.
CockroachDB handles this. Its leaseholder mechanism assigns a single node as the coordinator for each range of data. Reads are served locally from the leaseholder. Writes go through Raft consensus but require only a majority quorum. If one replica is temporarily further away due to orbital mechanics, the other two can still commit the write.
However, optimal leaseholder placement on the ground is a function of user geography: Place the leaseholder near the users who read the data most frequently. In orbit, "near" is not a fixed concept. The leaseholder that is closest to the ground station in Singapore right now will be over the Indian Ocean in twelve minutes and over East Africa in twenty-four.
More broadly, orbital computing transforms what "local" means. On Earth, locality is primarily geographic. In orbit, locality becomes temporal as well, because the optimal location for serving data changes continuously as satellites move. Database architecture must adapt to both dimensions.
VIII. Does relativity matter for an orbital database?
Surprisingly, relativity is not the primary engineering challenge for an orbital database. A satellite at 550 kilometers altitude moves at 7.66 kilometers per second through a gravitational field weaker than the one on the surface below. The reader familiar with GPS will expect this to matter: GPS satellites carry atomic clocks that drift 38 microseconds per day due to relativistic effects, and the system would be useless without corrections. Surely a database in orbit must contend with the same physics.
At 550 kilometers, general relativity causes the onboard clock to run approximately five microseconds per day fast, because gravity is weaker and time passes more quickly further from the mass. Special relativity causes it to run approximately 28 microseconds per day slow, because the satellite is moving at orbital velocity and moving clocks run slow. The net drift is roughly 23 microseconds per day. The orbital clock falls behind the ground clock by about 0.27 nanoseconds every second.
CockroachDB does not use atomic clocks. It uses hybrid logical clocks, a mechanism that combines a physical timestamp with a logical counter to establish a consistent ordering of events across nodes. The system is designed to tolerate clock skew. Its default maximum offset is 500 milliseconds. The relativistic drift across the duration of a database transaction, which completes in milliseconds, is on the order of picoseconds. That’s smaller than the tolerance by a factor of roughly one trillion.
The physics that the public associates with space, the curvature of spacetime, the dilation of clocks, the warping of simultaneity, is irrelevant to the engineering of an orbital database. The physics that matters is far more mundane: the propagation delay of light across a laser link, the changing topology of a constellation as it rotates, and the three-millisecond penalty for every message that must traverse the atmosphere. Einstein is not the problem. Newton is the problem.
In other words, the limiting factor isn’t exotic physics. It’s the practical realities of moving data across a changing network fast enough to maintain consistency.
IX. How should databases adapt to moving satellite networks?
Databases operating across satellite constellations must continuously adapt to a network whose topology is always changing. The challenge of optimal leaseholder placement in an orbital constellation is about geometry, not databases. A constellation of satellites forms a mesh, which is embedded on a set of orbital shells. Each shell is a sphere at a fixed altitude, and the satellites trace geodesics on that sphere, which is to say, great circles. The mesh is not static; it rotates, and the relative distances between nodes on different orbital planes change continuously as the planes precess.
The latency between any two nodes is a function of the geodesic distance on the mesh at a given moment, modified by the routing topology of the laser links. The optimal leaseholder placement for a given range of data is the node that minimizes the expected latency to the set of clients accessing that range.
On the ground, this optimization is performed periodically and produces a static assignment: leaseholder for range R goes to node N in region X. In orbit, the optimal assignment drifts continuously. The leaseholder that minimizes latency at minute zero is suboptimal by minute six and possibly the worst choice by minute forty-seven.
A simple approximation may suffice for early deployments: Precompute a periodic leaseholder schedule based on the known orbital elements. The constellation repeats its geometry every orbital period, roughly 95 minutes for a 550-kilometer orbit. The leaseholder placement repeats with it. The database could carry a timetable, like a train schedule, rotating leaseholders through a predetermined sequence.
This would not be optimal. However, it would be correct, and correctness – at 550 kilometers – matters more than optimality.
X. How does data sovereignty work in orbit?
Data sovereignty becomes significantly more complex in orbit because satellites routinely cross national jurisdictions. A satellite in low Earth orbit at 550 kilometers altitude completes one orbit in approximately 95 minutes. In that time, it crosses over dozens of national jurisdictions. The ground track of a single orbit might pass over Canada, the Atlantic Ocean, Portugal, Algeria, Niger, Chad, the Central African Republic, the Democratic Republic of Congo, Zambia, Mozambique, the Indian Ocean, and Australia before the satellite has completed half its circuit.
Data sovereignty laws are defined by terrestrial borders. The European Union's General Data Protection Regulation applies to the personal data of EU residents, regardless of where the data is physically stored. But "where the data is physically stored" has always meant a building with an address. A rack with a serial number. A jurisdiction with a court.
A satellite over Portugal holds a copy of a row written by a user in Frankfurt. Ninety-five minutes later, that satellite and that row are over the Pacific. Does this constitute a cross-border data transfer? That’s a question that no existing regulation was written to answer. However those questions are ultimately resolved, they will influence far more than database design. They’ll shape where regulated industries can deploy orbital applications, how global services satisfy regional compliance requirements, and which governance models emerge for computing beyond terrestrial infrastructure.
CockroachDB's zone configurations allow operators to pin data to specific localities. On the ground, this means constraining replicas to specific regions: EU data stays in EU data centers. In orbit, the "EU data center" is an EU data center for approximately eight minutes per orbit. Then it’s an Atlantic data center, then an African data center...
The database can be configured to replicate data only to satellites that are currently over approved jurisdictions. But "currently" changes every few minutes, and re-replicating data at orbital velocity would generate more network traffic than the laser links could carry.
The more practical approach: define sovereignty by the satellite's registration, not its position. A satellite registered in the EU and operated by an EU entity could be considered EU territory for data purposes, much as a ship flying a flag is subject to the laws of its flag state regardless of its location at sea.
XI. What happens when an orbital database node disappears?
An orbital database must distinguish between nodes that are temporarily unreachable and those that are permanently lost. On the ground, when a CockroachDB node fails, an operator investigates. The node might be restarted, its disk replaced, its data rebalanced to surviving nodes.
CockroachDB's decommission process is designed for planned removals. An operator marks a node as decommissioning, and the database migrates its data to other nodes before shutting it down cleanly. This process assumes the node is reachable and cooperative.
But there is a subtlety. On the ground, a failed node might come back. The operator reboots it, and it rejoins the cluster with its data intact. The database reconciles the returning node's state with the current state and continues. In orbit, a node that goes silent might return after a brief communication blackout caused by orbital geometry, or it might never return because it has reentered the atmosphere.
The database can’t distinguish between these cases in real time. The Raft protocol doesn’t include a field for "this node is burning up over the South Pacific." The liveness timeout must be tuned carefully: too short, and the database will replicate data unnecessarily every time a satellite passes behind the Earth relative to its peers; too long, and the cluster operates with reduced redundancy while waiting for a node that will never return.
Hardware obsolescence introduces another dimension. For example, Nvidia releases new GPU architectures faster than satellites can be manufactured and launched. A constellation deployed in 2028 may contain hardware that is two generations behind by 2030. Rolling upgrades, the standard method for updating CockroachDB, require taking nodes offline and replacing the binary. In orbit, "replacing the binary" is possible through software updates. Replacing the hardware is not. The node's CPU, memory, and storage are fixed for the lifetime of the satellite, which may be five to ten years.
CockroachDB has always been hardware-agnostic. It runs on whatever the operating system provides. In orbit, this property becomes essential: The database must continue to operate on aging hardware while newer satellites join the constellation with faster processors and larger storage. The cluster must absorb heterogeneous nodes gracefully, routing more work to the faster nodes and less to the older ones.
This is, again, something CockroachDB already does. It just hasn’t done it at orbital timescales.
XII. What would orbital databases still need?
Existing distributed databases could operate in orbit today, but they would require new capabilities to become truly orbital-aware. CockroachDB would function in an orbital constellation today. It would get there and survive. It would not be optimized for the environment, however.
Many of these capabilities would have value beyond orbital computing. As infrastructure becomes increasingly dynamic, whether because of mobile edge deployments, autonomous systems, or future space-based platforms, the ability for distributed databases to adapt automatically to changing topology, latency, and failure domains becomes broadly applicable.
The features that a space-based database deployment would require don’t yet exist, including:
Dynamic localities. The current locality system assumes that a node's position in the topology is fixed. A node in us-east stays in us-east. An orbital node's effective locality changes continuously. The database would need a locality system that accepts position updates and adjusts replica placement accordingly, or a higher-level abstraction that treats orbital shells and planes as stable localities while acknowledging that their relationship to the ground shifts with time.
Orbital-aware leaseholder policies. Leaseholder placement today is driven by access patterns observed over time. In orbit, the access patterns are predictable from physics. The database should accept an orbital model and pre-compute leaseholder schedules, rather than discovering the optimal placement reactively through latency observations.
Autonomous decommission. The current decommission workflow requires an operator to initiate the process. An orbital node that is clearly failing should be able to trigger its own decommission and migrate its data to surviving nodes without waiting for humans or agents to issue a command from the ground.
Jurisdiction-aware replication. Zone configurations would need a temporal dimension: “This data may reside on this node only while the node is over an approved jurisdiction.” That’s likely impractical at fine granularity, but the framework for expressing the constraint should exist, even if the initial implementation uses flag-state semantics rather than real-time position.
History suggests that infrastructure evolves by solving tomorrow's problems before they become mainstream. Distributed databases were built to tolerate failures across regions and continents long before anyone imagined constellations of orbital data centers. If computing continues to expand beyond Earth's surface, the next generation of distributed systems may prove that some of today's most resilient architectures were already pointing in that direction.
These are engineering problems and they are solvable. Orbital engineering is dominated by considerations of weight. Data doesn't have physical weight, but it does have operational weight. It must be replicated. It must be consistent. It must survive.
Related
CockroachDB: The Definitive Guide, 2nd Edition (O'Reilly) — a practical deep dive into multi-region deployment, survival goals, and resilience for readers who want to go from thought experiment to production.
This post draws on reporting by Eric Berger in Ars Technica, March 2026.
Isaac Wong is EVP of Research & Development at Cockroach Labs, where he leads the engineering organization behind CockroachDB to shape the company's long-term technical vision. He oversees the teams driving the database's core architecture, reliability, and continued innovation.
