The Short Answer
Yes — and as of 2026 it is a mainstream architecture, not a hack. Object-storage-backed vector search keeps vectors in cheap, durable blob storage (S3, GCS, B2) and pulls only the relevant slices through a cache at query time, trading single-digit-millisecond latency for roughly an order of magnitude lower cost. AWS made the pattern official when S3 Vectors went GA in December 2025 claiming up to 90% cost reduction; turbopuffer, LanceDB, and Mixpeek MVS had been shipping variations of the same idea. If your corpus is large, your query rate is moderate, and 100ms-class latency is acceptable, storage-first is usually the right default. If you need sub-10ms everywhere, you still want RAM.
Why would you put vectors on object storage?
Economics, mostly. A conventional vector database keeps every vector (plus graph structure) in memory or on local NVMe, triple-replicated for durability — you pay for peak capacity around the clock, whether or not anyone is querying. Object storage inverts that: durability is the storage layer's problem (eleven nines, versioning, cross-region replication for cents per GB-month), compute scales to zero when idle, and capacity is effectively unbounded. The delta compounds at scale: a billion 768-dimensional float32 vectors is ~3TB raw — a large, always-on cluster in the RAM model, but a rounding error of monthly storage cost on S3. That is why the pattern took over the long tail of workloads: massive corpora, bursty or infrequent queries, multi-tenant platforms where most tenants are cold at any given moment.
How does vector search on object storage actually work?
Every serious implementation converges on the same four ideas:
| Component | What it does | Why it exists |
| Immutable segments | Vectors land in append-only, LSM-style files; updates write new segments and background jobs compact | Object storage cannot cheaply mutate bytes in place |
| Coarse partitioning | Centroid/IVF-style clustering so a query touches a handful of partitions, not the whole index | Each fetch is a network round-trip; the game is fetching less |
| Quantization + rescoring | Compressed vectors (PQ, binary, int8) answer the broad search; full-precision vectors rescore the short list | Shrinks both storage and bytes-per-query, recovers accuracy at the end |
| A cache tier | Hot partitions live on local NVMe or in memory; cold ones stream from the bucket | Turns second queries from ~1s cold into ~100ms warm |
When is a storage-first vector database the wrong choice?
Three honest disqualifiers. Hard real-time serving: if every query must return in under ~10ms (ad ranking, autocomplete), in-memory HNSW still wins and no cache tier saves the cold path. Mutation-heavy workloads: constant deletes and per-record updates fight the immutable-segment model; compaction lag becomes visible. Tiny corpora: under a few million vectors, a library (FAISS, hnswlib) or pgvector embedded in the database you already run is simpler than any dedicated system. For everything in between — archives, media libraries, RAG corpora, agent memory — the cost curve usually decides in favor of object storage. For the tiering mechanics, see vector storage tiering; for how deletes and updates propagate, index freshness and incremental updates.
What does bring-your-own-bucket add?
Most storage-first systems put vectors in *their* object storage. Running the store over a bucket you own is a different posture: the vectors, payloads, and indexes live in your S3/GCS/B2 account, under your IAM policies, your compliance boundary, and your lifecycle rules — the vendor operates the compute, not the custody. That matters for regulated data, for egress economics, and for exit: leaving means repointing compute, not exporting a database. Mixpeek MVS is built this way — dense, sparse, and BM25 hybrid search over vectors in your own object storage, with filtered search and score fusion running server-side, 1M vectors free, and migration paths from Pinecone, Qdrant, and Weaviate that keep your existing embeddings. If you are comparing the whole landscape first, start with the best vector databases and the best S3-compatible object storage for AI workloads.
How do the object-storage vector options compare?
| System | Model | Scale claims (published) | Notes |
| Amazon S3 Vectors | Managed, AWS-native | 2B vectors/index, 10K indexes/bucket, ~100ms warm | GA Dec 2025; 31+ regions; pay per PUT/storage/query |
| turbopuffer | Managed, storage-first | Documented architecture on object storage + NVMe cache | Serves production search for large SaaS workloads |
| LanceDB | Open format + embedded/managed | Columnar Lance format over any object store | Strong for local-first and ML-pipeline embedding |
| Mixpeek MVS | Managed compute over YOUR bucket | 1M vectors free; dense+sparse+BM25 hybrid | BYO S3/GCS/B2; multimodal payloads; migration tooling |
| Milvus / Zilliz | Cluster with tiered storage | Hot/cold tiering to object storage | Cluster-first design with object-storage economics bolted on |
Where is this going?
The direction of travel is clear: compute-storage separation won databases (Snowflake, BigQuery), then logs (WarpStream-style Kafka), and vectors are following. As embedding models shrink dimensions (Matryoshka truncation, binary quantization) the bytes-per-vector keep falling, which makes the object-storage path cheaper still. The likely end state is that "vector database" stops being a place you copy your data into and becomes a query layer over storage you already own — which is the premise MVS starts from, and a big part of why we wrote this guide from production experience rather than theory. Pricing for the managed side is on pricing; the free tier needs no card.