Storage Had Gravity: How Atlas Infinite Makes Read Replicas Zero-Copy

Storage Had Gravity: How Atlas Infinite Makes Read Replicas Zero-Copy

In October 2024, a MongoDB engineer sat in a meeting drawing straws over who had to tell a customer the bad news: expanding storage on their cluster would take several days. The database was not misbehaving. Like nearly every database in production, it kept its data on disks bolted to the machines computing over it, and every storage-shaped operation (resizing, restoring, adding a read replica) reduces to one primitive: copy a very large amount of bytes from one machine to another. Better software does not make a terabyte weigh less.

MongoDB's answer is Atlas Infinite, in public preview since September 29, 2026 alongside MongoDB 9.0. The October 8 architecture post is worth reading even if you never touch Mongo: it says the quiet part out loud about what disaggregation actually costs.

The idea is not new, and MongoDB says so

Compute and storage on separate machines has existed commercially for at least a decade. Amazon Aurora shipped it in 2017, Snowflake built a company on it, and Neon plus a wave of Postgres services run on the same shape. MongoDB waited, and the explanation is candid: the properties that make their engine fast are the ones that make it hard to pull apart. They refused to give up the speed or the isolation model customers had.

Why WiredTiger fights the textbook

WiredTiger, MongoDB's storage engine, earns its speed by deferring and batching work. It uses checkpoint-based consistency: a page absorbs many mutations in memory and gets written to disk once, at a checkpoint, instead of logging every change. The decade-old disaggregation recipe breaks that. It ships a physical redo log obligated to record every page change so a shared tier can reconstruct any page version. Adopt it directly and you trade away the engine's core efficiency to buy elasticity. Three other problems made it worse:

• No canonical bytes. WiredTiger is lock-free, parallel, and evicts pages speculatively. Two nodes holding identical logical data will not hold identical bytes on disk, so "replicate the pages" has no well-defined target.
• Cleartext. Conventional designs ask the shared layer to read and rewrite your data in the clear. MongoDB rejected that: if your data is unencrypted, it does not enter the shared layer.
• Replica lag. A replica that only sees data at checkpoint boundaries lags by seconds, not milliseconds. The design had to keep batched writes and millisecond freshness at once.

Three machines become fourteen

Atlas Core, the starting point, is a classic replica set: three nodes, each a complete machine with a full copy of the data on its own attached disk, kept in step by oplog replication. Simple, robust, cleanly isolated. Also, anything you want to do to the data you have to do to the whole machine.

Atlas Infinite splits the cluster in half. The compute layer keeps the database duties (parsing, transactions, aggregations) and nothing else: a primary, a standby, optional read replicas, all stateless and inside the customer's own VPC. The storage layer is multi-tenant, purpose-built in Rust, and made of services that scale, fail, and recover independently. MongoDB's edge is structural: they own the whole stack, engine, server, and cloud, so they could reach into the engine rather than bolt disaggregation onto it from the outside.

• Log Service. Every write becomes an append to a replicated log, and the service does exactly one thing: reach consensus on it. A service that does one thing can be verified, fast, and have a tighter tail than one juggling durability alongside full database duties.
• Page Service. A pool of page servers in each availability zone holds materialized pages warm and answers page reads. A page materializer reads entries as they hit the log, distributes them to the servers that own each log, and spools the log down to object storage.
• Object Index Service over S3, GCS, or Azure Blob. The durability floor. An Object Read Proxy answers the same shape of read query from object storage, which is what makes time travel and continuous data protection workable.

The front door does not move. Same wire protocol, same drivers, same semantics. The application cannot tell the difference.

The three operations that stop costing the size of the database

Whether the split is real shows up in operations that used to be expensive:

The common thread: each operation touches only the layer that has to change, and its cost scales with the size of the change, not the database. A new replica pays for the oplog tail, which is small, instead of the database, which is neither.

The write path keeps WiredTiger's habits intact. A write appends an oplog entry, the Log Service replicates it across three zones, and the write is acknowledged the moment a majority holds it durably. Pages stay in memory and get written in batches at checkpoint, as before. The log gives durability, the materializer gives readability, and the two no longer block each other.

The line they refused to cross

Every disaggregated database has to decide whether the shared storage layer can read your data. For most, it can, and that is not a bug. A tier that reconstructs pages from a redo log must interpret those pages, and interpreting data means reading it. Defenses around that fact are operational: access controls, scoped credentials, audits. Translation: trust us.

Atlas Infinite draws the boundary cryptographically instead. Pages are encrypted on the single-tenant compute node before a byte goes down, decrypted in exactly one place, and the keys can be yours to hold, rotate, and revoke. The storage fleet cannot see documents, collection names, or indexes; an operator with root on the entire fleet holds opaque bytes. Their framing is "trust our algorithm, not us," and that is the most transferable idea in the post. Decide early whether your shared layer is allowed to read the payload; retrofitting blindness into a system built to interpret is brutally hard.

What to take from it

Some calibration first: this is a vendor preview, and the durability, availability, and latency numbers are MongoDB's own. Disaggregation does not make sharding obsolete; write scale on a single replica set still has a ceiling. And fourteen services did not stop existing, they moved behind someone else's glass and into someone else's pager rotation.

Still, the checklist generalizes to any store you design or buy. List every operation whose cost scales with the size of your data; each one has a log-fork or shared-cache version hiding in it. Decide what your shared layer is allowed to read, as a design constraint, not a security afterthought. How data should sit on your disk got a new answer: it shouldn't. Storage had gravity. It's lighter now, at least inside their preview.