NEWVectors or files. Pick a path.Start →
    Back to DiagramsProduct

    MVS Architecture: Object Storage Is the Database

    Object storage is the database. A query planner fans out across segments and merges, and the segments themselves are cheap to drop because the bucket already holds everything they need.

    A layered architecture diagram. Your application, reaching MVS over SDK, REST or MCP, feeds a query planner that runs one per namespace and does plan, fan out, score and merge. The planner fans out to four segments; three are active and each carries dense, sparse, BM25 and payload, while the fourth is drawn dashed as a cold segment restored on first query. All four converge on your object storage, an S3, GCS or R2 bucket holding vectors, payloads and index snapshots. A right-hand rail shows where a segment lives: hot and resident, warm in local cache, or cold in object storage, with a note that tiers move on their own and an index nobody queries scales to zero.
    Object storage is the database. A query planner fans out across segments and merges, and the segments themselves are cheap to drop because the bucket already holds everything they need.

    Most vector databases ask you to move your embeddings into their storage, then keep a cluster warm so queries stay fast. You pay for that cluster whether anyone searches or not, and the bill tracks the size of the corpus rather than the traffic against it.

    MVS treats your bucket as the database. Vectors, payloads and index snapshots all live in object storage you own, and search runs against them there.

    A query arrives through the SDK, REST or MCP and hits a query planner, one per namespace. The planner plans, fans out, scores and merges. It fans out to segments, and each segment answers dense, sparse, BM25 and payload filters over its own slice, so one query covers all four without you running three systems and reconciling the rankings yourself.

    Segments are cheap to throw away, which is the part that makes the economics work. Everything a segment needs is already in the bucket, so a cold one is restored on first query rather than kept alive against the chance of one. Hot means resident. Warm means a local cache with no fetch. Cold means object storage. Tiers move on their own and an index nobody queries scales to zero.

    That is where the published 10 to 80 times cost range at scale comes from: quiet corpora stop costing money.

    What this diagram leaves out is how the segments are implemented. If that is the conversation you want, book the architecture review and we will run it on your workload.

    Where this diagram appears

    Bring your own vectors

    Dense, sparse and BM25 search on the object storage you already pay for. From $25/mo.

    Explore MVS

    Related diagrams

    A three-band architecture diagram of the Mixpeek Vector Store write path on object storage. The top band runs left to right: a client write of an upsert or delete, into a write-ahead log where the append happens and the acknowledgement returns, then a segment sealing as immutable, then shipping to object storage. A callout under the log reads that the acknowledgement happens there and not after indexing, and a dashed box spanning the seal and ship steps marks a leader fence on the append as planned rather than shipped. The middle band is your object storage, an S3 or GCS bucket holding one sequenced object per sealed segment at the path wal slash namespace slash shard slash sequence dot wal, drawn as a row of numbered segments with the two oldest greyed. Beside them, snapshots compact the chain and commit to object storage, and a garbage-collection gate states that a segment is deleted only once its writes are provably inside a committed snapshot. The bottom band fans out to three readers of the same chain: recovery, which takes the latest snapshot plus a replay of shipped segments; replicas, which tail the chain to stay in sync; and change data capture, which reads the chain as an event feed.

    Write-Ahead Logs on Object Storage: The MVS Write Path

    Diagram placing BM25, SPLADE and dense embeddings on a single axis measuring how much vocabulary survives compression, with what each one stores and why production systems run more than one.

    Sparse and Dense Are One Spectrum, Not Two Camps

    Diagram comparing memory-resident vector search against storage-first vector search on object storage, showing the cost structure of a billion 768-dimensional vectors under each model.

    The S3 Vector Warehouse: Storage-First Vector Search