Vector

Vector is an MIT-licensed, stateless search engine built on SlateDB and object storage. It stores documents against a user-defined schema with dense vector and text fields, and serves both approximate nearest neighbor (ANN) search over the vectors and full-text (BM25) search over the text. Because all state lives in object storage, any node has full access to all data, a single replica is fully durable, and you can scale query throughput by adding stateless reader replicas.

​

What it’s good at

• Online ANN search from object storage. Warm queries run in the single-digit to low-teens milliseconds while the index lives durably on object storage.
• Full-text search. Text fields are tokenized and BM25-indexed on write, so the same engine serves keyword search alongside vector search, with the same filters and result format. Pair the two for hybrid relevance.
• Simple, durable deployment. A single pod never loses data and fails over in seconds. Read replicas have no communication with the writer, so you scale reads without coordination.
• Stable incremental ingest. A lazy adaptation of the LIRE protocol on top of SlateDB merges keeps ingest throughput steady as the index grows, with no expensive graph rebuilds.
• Flexible topologies. Run embedded in your application, as a single node, as a writer with read replicas, or with buffered ingest through OpenData Buffer.

​

Why Vector

Vector fills the gap between running pgvector and pg_search yourself and paying a vendor many multiples of hardware cost to operate a search database for you. A truly stateless architecture is what makes Vector cheaper and easier to operate than earlier vector databases. Any node can serve any data, so there are no shard assignments to manage and no rebalancing when nodes come and go. The index is an inverted file (IVF/SPANN) tuned for object storage: it batch-loads index data per round trip rather than making the sequential, hop-by-hop reads a graph index requires, so cold queries stay fast despite object-store latency. Reads and writes are fully decoupled, so you can capacity-plan ingest and query independently. See the benchmarks for recall, warm and cold query latency, ingest throughput, and cost across standard datasets, along with a harness you can point at your own data.

​

Tradeoffs

• Warm versus cold latency. IVF scores more vectors than a graph index like HNSW, so warm queries are in the milliseconds rather than sub-millisecond. In exchange, cold queries stay sub-second where a cold HNSW graph can take dozens of seconds to load.
• Write latency. Vector batches writes to amortize object-store PUTs and indexing work, so a write can take up to about a second to acknowledge. Putting Buffer in front cuts that to roughly a hundred milliseconds, without read-your-writes.
• Attribute filtering on vector queries. Filters run after the ANN index yields candidates, so recall on heavily filtered vector queries can suffer.
• No single-query hybrid search. ANN and BM25 scores are not 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.

​

Explore Vector