Topic 5.3
Kinds of Vector Stores
In one line
Vector stores come in four families: dedicated vector databases, search engines with vector fields, extensions to a database you already run, and embedded libraries. They differ in where the data lives and who operates it, not in what a search means.
Think of it like this
To keep tools you can buy a separate workshop, rent a bench in a shared workshop, add a toolbox to the garage you already have, or just carry a toolbag. All four hold tools. They differ in cost, space and who looks after the place. Vector stores are the same.
Words you'll meet
New words in this topic, in plain English. Come back here whenever one feels fuzzy.
- Dedicated vector database
- A system made only for storing and searching vectors, run as its own service.
- Managed service
- A product run by a vendor in their cloud, so you do not operate the servers.
- Self-hosted
- You run the software on your own machines or cloud account.
- Embedded
- Runs inside your application's process, with no separate server.
- Vector field
- A column or field type in a search engine or database that holds a vector.
- Lock-in
- How hard it is to move away from a product after you depend on it.
- Interface
- The small set of calls the rest of the code uses, so the implementation behind it can change.
Step by step
01Step 1: write down what you need first
List how many vectors, how many writers, which filters and whether you need keyword search too. Without that list every product looks right.
02Step 2: find your family
Already run PostgreSQL or a search engine? Try its vector feature first. A prototype or one-process tool? An embedded library. Very large scale or a need for vector-first features? A dedicated service.
03Step 3: run the two-store example
ExactStore compares the query with all ten points. BucketStore puts each point in one of four quarters of a circle and compares only the query's quarter. Both have add and search, so the calling code is identical.
04Step 4: read the three queries
At 20 degrees and 230 degrees the bucket store gives the same two answers as the exact store while comparing fewer points. At 85 degrees the second-nearest point sits just across a boundary (at 95 degrees), so the bucket store misses it. Widening to the neighbouring quarters finds it again, at the cost of comparing more points. This is what nprobe and ef_search do in a real index.
05Step 5: keep the choice reversible
Put the store behind an interface (Topic 5.9). Keep your source documents and the embedding model name so you can rebuild the store in another product. The expensive part of leaving a store is usually re-embedding, not the code.
Try it yourself
- 1
Move a point
Change point
dfrom 95 to 88 degrees. Which bucket is it in now, and does the 85-degree query find it without widening? - 2
Add a point on the boundary
Add a point
kat 91 degrees and a query at 89. Predict the plain bucket result, then run. - 3
Count the cost of widening
For each query, compare the counted points of the plain and the widened search to the exact search. How much work does widening save on the 20-degree query?
Code & diagrams
Real approximate indexes (IVF, HNSW) are smarter than four buckets, but they make the same trade: look at less, risk missing a neighbour near a boundary.
Expected output
query 85 deg: exact c,d (10 compared) | bucket c,b (3) | widened c,d (8)
query 20 deg: exact a,b (10 compared) | bucket a,b (3) | widened a,b (8)
query 230 deg: exact h,g (10 compared) | bucket h,g (2) | widened h,g (7)Break it on purpose
Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.
Break #1
Query across a boundary without widening
In the Python tab, change the first query degree from 85 to 89 and call only the plain bucket search (leave the line as it is). Run.
Myth vs fact
Myth
A dedicated vector database is always better than a general database.
Fact
It depends on your scale, filters and what you already operate. For modest data, a table in a database you run can be simpler and just as good.
Myth
All vector stores return the same results.
Fact
Exact stores do. Approximate ones can miss true neighbours, and the miss rate depends on the index and its settings.
Myth
You must pick the final store on day one.
Fact
Behind an interface, with source documents kept, you can change later. The re-embedding bill is what makes a late move expensive.
Pro corner
Extra depth for experienced readers. New to this? Skip it for now and come back later.
- ▸
Managed services remove operations work and add a network hop, a bill that grows with data and traffic, and a dependency on the vendor's availability. Self-hosting reverses all three.
- ▸
Ask what happens during a write burst: some stores make new vectors searchable immediately, others after a delay or an index merge (Topic 5.6).
- ▸
Check the data you must be allowed to send out. A managed service means your document text or embeddings leave your network. Embeddings can leak information about their text, so treat them as sensitive as the text.
Remember this
- 1
Why this topic exists. Searching the web for "vector database" shows dozens of products and every one claims to be best. You do not need a ranking. You need four families and the question each answers, so that you can place any product you meet. Names below are examples of a family, not recommendations and not a complete list. Features, licences and prices change often: read the current documentation before you decide.
- 2
Family 1: dedicated vector databases. Built only to store and search vectors, run as their own service (self-hosted or as a managed cloud service). Examples: Qdrant, Milvus, Weaviate and Pinecone (Pinecone is only offered as a managed service; the others can also be self-hosted). They usually offer rich filtering, several index types, scaling across machines and a vector-first API. You pay for another system to run, secure, back up and keep in sync with your source data.
- 3
Family 2: search engines with vector fields. General search engines that added a vector field type next to their keyword search. Examples: Elasticsearch and OpenSearch. If you already run one for keyword search, you get keyword and vector search in the same query, which Phase 6 needs (hybrid search), on a system your team may already operate.
- 4
Family 3: extensions to a database you already run. The vector type is added inside a general database. Examples: pgvector for PostgreSQL (Topic 5.2), and the vector search features of MongoDB (Atlas Vector Search), Redis and others. Your vectors sit beside your other tables or documents, with the same backups, permissions and transactions. The trade is that vector queries share the machine and tuning with everything else.
- 5
Family 4: embedded libraries. A library inside your own program, with no server. Examples: FAISS, hnswlib, and databases designed to run inside the application, such as Chroma in its local mode, LanceDB and sqlite-vec. FAISS and hnswlib are really index libraries: they search vectors but keep no text, payloads or filters for you, so you add those. The others store more. They are the simplest to start with and perfect for a laptop, a test suite or a single-process service. You handle sharing, concurrent writers and scaling yourself.
- 6
What stays the same. Whatever the family, you give the store ids, vectors and metadata, ask for the k nearest to a query vector with an optional filter, and get ids and scores back. That is the
VectorStoreinterface this phase builds (Topic 5.9). Approximate stores may miss a true neighbour, so measure recall (Topic 3.6) whatever the product. The example shows two stores behind one interface: one scans everything, one searches only a part, and the second needs a wider search to find a neighbour across a boundary. - 7
Questions that place a product. Where does it run (your process, your servers, a vendor's cloud)? Who writes to it and how often? Does it support filters inside the search (Topic 5.5)? Does it support keyword plus vector search (Phase 6)? How does it scale: bigger machine, more machines? What does it cost to run, and what does it cost to leave?
Explain it without notes
Name the four families of vector stores and one example of each.
What does every vector store have in common, whatever the family?
Why can an approximate store miss a true nearest neighbour?
What makes a late move between stores expensive?
Practice
Write family(vectors, uses_postgres) that returns "embedded", "extension" or "dedicated" using rules of your choice, and print it for these three profiles: (a) 5,000 vectors in a single-process tool, (b) 2 million vectors in a product that already uses PostgreSQL, (c) 400 million vectors that need many machines. Print the answer for each.
Write recall_at_k(exact_ids, found_ids) that returns the fraction of exact ids that the approximate result found. Print it for exact ["c", "d"] and found ["c", "b"].
Trade-offs
- ↔
Dedicated: vector-first features and scale, one more system to operate.
- ↔
Search engine: keyword and vector search together, usually heavier to run than a table.
- ↔
Extension: fewest new parts, shared resources.
- ↔
Embedded: simplest and fastest to start, no sharing between processes.
Done when you can
Done when you can name the four families and place a product in one.
Done when you can list the questions that tell products apart (where it runs, writers, filters, hybrid search, scaling, cost).
Done when you can explain why a bucket-style index can miss a neighbour near a boundary.
Done when you can explain how an interface keeps the choice reversible.