Why put a database write-ahead log on object storage?

Because it moves the durability promise off disks you babysit and onto the bucket's eleven nines. MVS acknowledges each write into an append-only log, seals segments, and ships them to object storage as sequenced objects roughly every 20 seconds under production load. Everything downstream reads that one chain: recovery replays it on top of the last snapshot, replicas tail it, and change data capture consumes it again, so a dispute between any two stores can be settled by replaying the log.

How does MVS stop a deposed writer from forking the log?

Only one writer may append, and a deposed leader that never learned it was deposed is the dangerous case. Every segment ship checks a leader lease object and the writer's boot identity before it lands, and a full compare-and-swap protocol with a fencing epoch is in flight to fence even a writer that is silent through its own deposal. The write rate makes this cheap: one conditional control-plane write per 20 seconds per chain sits about 100x under the slowest provider's conditional-write ceiling.

Can garbage collection delete WAL segments the system still needs?

No. GC may delete a segment only when its writes are provably inside a committed snapshot, tracked by a durable-confirmed frontier that advances only after a snapshot's object-store commit succeeds. If the snapshot pipeline stalls, the frontier stops and GC deletes nothing, and retained-segment counters plus per-pass logs make that refusal loud, so a stuck pipeline shows up as a visible alarm rather than silent unbounded growth or, worse, deleted truth.

MVS Puts Its Write-Ahead Log on Object Storage

Name: MVS Puts Its Write-Ahead Log on Object Storage
Uploaded: 2026-08-25T17:00:00Z
Duration: 90 s

Multimodal Search in Action

Mixpeek Team

August 25, 2026

Summary

MVS, Mixpeek's vector store, acknowledges writes into an append-only write-ahead log and ships sealed segments to object storage as sequenced objects (wal/namespace/shard/sequence), roughly one every 20 seconds under production load. The bucket's eleven nines of durability become the durability promise. Recovery replays the chain on top of the last snapshot, replicas tail it, and change data capture reads it again: one log, three readers. Coordination is the differentiated part. Only one writer may append, every ship checks a leader lease and the writer's boot identity (a compare-and-swap fencing epoch is in flight), and garbage collection deletes a segment only when its writes are provably inside a committed snapshot, with counters that make every refusal loud instead of silent. The measured ship rate is 0.05 per second per chain against provider conditional-write ceilings of 5 to 98 per second: about 100x headroom, with chains already partitioned per namespace and shard. Learn more: mixpeek.com/mvs and docs.mixpeek.com/vector-store/overview

mvswrite-ahead-logobject-storagedurabilityvector-storearchitecture

MVS Puts Its Write-Ahead Log on Object Storage

Summary

About this video

Frequently Asked Questions