> ## Documentation Index
> Fetch the complete documentation index at: https://opendata.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# When to choose Vector

> How OpenData Vector compares to turbopuffer, Pinecone, Qdrant, Milvus, Weaviate, Chroma, LanceDB, and pgvector

*We build OpenData and this is our best good-faith comparison. Corrections are
[welcome](https://github.com/opendata-oss/opendata/issues).*

Vector's architecture is heavily inspired by [turbopuffer](https://www.turbopuffer.com/):
object storage is the only source of truth, query serving nodes are
stateless caches, and the index is designed around object storage's latency
profile. Vector is that architecture as MIT-licensed software running in your
own account.

## Choose Vector if you care about…

**…paying proportional to your hot data, not your full dataset.** Cold
vectors sit on S3 at
[\~\$0.02/GB-month](https://aws.amazon.com/s3/pricing/), and compute is sized
for what's actually being queried. In
[our benchmarks](/vector/benchmarks), one \$346/mo node serves 100M vectors.
If most of
your vectors are cold most of the time (per-tenant and per-user indexes are
the classic case), the difference is hundreds versus thousands of dollars
per month.

**…a durable deployment that's one process and a bucket.** Every byte of
data and metadata lives in an object store bucket, so there is no
replication to manage and you can kill every compute node without losing
anything. There are no supporting services to run: scaling reads means
adding stateless replica pods that don't communicate with the writer or
each other.

**…an online database.** Concurrent clients upsert and query a single
incrementally maintained index, rather than a serving layer you assemble
yourself around a file format.

**…owning your search infrastructure.** MIT licensed, running in your
bucket and your VPC. There is no per-query pricing, data doesn't leave your
account, and no vendor can reprice or discontinue the software.

## How the alternatives stack up

✓ = yes · \~ = partially · ✗ = no

| You care about…                            | **Vector** | turbopuffer | Pinecone    | Qdrant / Weaviate  | Milvus       | Chroma (distributed) | LanceDB (OSS) | pgvector     |
| ------------------------------------------ | ---------- | ----------- | ----------- | ------------------ | ------------ | -------------------- | ------------- | ------------ |
| Cost proportional to hot data              | ✓          | ✓           | \~ ¹        | ✗                  | \~ ²         | ✓                    | ✓             | ✗            |
| Durable deployment: one process + a bucket | ✓          | managed     | managed     | ✗                  | \~ ²         | \~ ³                 | \~ ⁴          | ✗            |
| Online database, consistent writes         | ✓          | ✓           | ✓           | ✓                  | ✓            | ✓                    | ✗ ⁴           | ✓            |
| License                                    | MIT        | Proprietary | Proprietary | Apache 2.0 / BSD ⁵ | Apache 2.0 ² | Apache 2.0 ³         | Apache 2.0    | PostgreSQL ⁵ |

¹ [Pinecone serverless](https://docs.pinecone.io/reference/architecture/serverless-architecture)
tiers to object storage internally, but you buy it at managed-service prices
rather than S3 prices in your own account. \
² Milvus distributed uses object storage for durability but manages stateful shard
assignment and etcd and a WAL/messaging layer. It's a cluster rather than a single
process. \
³ Distributed Chroma is the nearest open-source system: Apache 2.0 and
genuinely object-storage-backed.
Operationally it's a multi-service topology (frontends, query nodes,
compactors, metadata) with collection-to-node routing, primarily offered as
Chroma Cloud/BYOC. Single-node OSS Chroma is SQLite-backed rather than
object-store-native. \
⁴ [LanceDB OSS](https://github.com/lancedb/lancedb) is an embedded library
over files. That works well on object
storage for pipelines, but the online serving layer is its commercial cloud. \
⁵ Open source, but durable state lives on replicated node disks: self-hosting
means operating a stateful cluster, and cold data pays SSD prices.

turbopuffer matches Vector on everything except the license. The
open-source systems each lack either the stateless operations or the online
database. Vector is the MIT-licensed system with both.

## The tradeoffs

* **Latency:** warm queries run in low-single-digit to low-teens
  milliseconds (dataset-size dependent), cold queries up to \~1s at p90. This is fine
  for RAG and search, but not ideal for uniformly hot, sub-millisecond serving.
* **Writes are batched:** durable acks can take \~1s, or \~100ms fronted by
  [Buffer](/buffer) at the cost of read-your-writes.
* **No single-query hybrid search:** Vector serves both ANN and BM25
  full-text queries, but their scores aren't comparable, so a query scores
  by one or the other. To blend semantic and keyword relevance, run both and
  fuse the result lists client-side.

***

*Last reviewed July 2026. Please
[tell us](https://github.com/opendata-oss/opendata/issues) if a claim has
gone stale.*