You can keep your vectors in S3 and search them there. Three ways work today. AWS S3 Vectors stores embeddings in a special bucket type and answers similarity queries through an API. LanceDB writes a columnar vector format to any S3 path and queries it from your process. A vector store built on object storage, such as Mixpeek's MVS, keeps the index and payloads in your bucket and runs dense, sparse and BM25 search over them. Pick by what you need beyond nearest neighbor: filters, hybrid keyword search, and how fast a cold query has to come back.
Why people move vectors to object storage
A hosted vector database keeps your whole index in memory on machines you rent all month. That is fine at a few million vectors. It gets expensive when most of your namespaces sit idle, which is the normal shape for multi-tenant apps and media archives.
Object storage flips the cost model. The data sits at storage prices, around $0.023 per GB-month on S3 Standard, and compute only runs when a query arrives.
The three options
S3 Vectors. Native to AWS. You create a vector bucket and an index, put vectors with metadata, and query by similarity. Good when you are all-in on AWS and need plain nearest-neighbor search with metadata filters.
LanceDB. An embedded library over the Lance file format. Point it at s3://bucket/path and query from your own code. Good when you want no server at all and your queries run inside one application.
A vector store on object storage. The index lives in your bucket, and a query layer loads what it needs, caches the hot parts, and scales idle namespaces to zero. MVS works this way: you bring your own vectors, run dense, sparse and BM25 hybrid search, and the vectors persist on your own S3-compatible storage. It also imports from Pinecone, Qdrant or Weaviate without re-embedding.
What to check before you switch
- Cold latency. The first query against an idle namespace has to fetch from storage. Measure it on your own data size.
- Hybrid search. If your users type exact product codes or names, pure vector search misses them. You want BM25 alongside dense vectors.
- Filters at query time. Metadata filters should apply inside the search. A store that filters the top results afterwards hands back fewer than you asked for.
- Write path. Check how writes become durable and searchable, and how long that takes.
Full details on how MVS does this, with a cost estimator: https://mixpeek.com/mvs
Disclosure: I work on Mixpeek.
Top comments (0)