Vector Store vs Vector Database: What's Actually the Difference

Vector Store vs Vector Database: What's Actually the Difference

One job posting demands "vector database experience." A product landing page promises a "built-in vector store." Someone in your team meeting insists you can just use Postgres. All three people are using the terms loosely, and the confusion is understandable because vendors blur them on purpose. There is a real distinction underneath, and knowing it will save you from both over-buying infrastructure and under-building your search layer.

Vectors, Quickly#

An embedding model converts any piece of text into an array of floats, maybe 768 or 1536 numbers long, positioned so that semantically similar inputs land near each other in that high-dimensional space. "How do I get my money back" ends up close to the refund policy section even though they share almost no words, because the model learned meaning rather than matching strings.

Search becomes geometry: embed everything once, then answer every future question by finding which stored vectors sit nearest to the question's vector. That is the entire trick behind semantic search, recommendations, and retrieval-augmented generation. Picture it flattened to two dimensions:

A Vector Store Is a Capability#

A vector store is anything that can hold embeddings and answer nearest-neighbor queries against them, usually alongside metadata for filtering. Notice what that definition does not require: servers, clusters, dashboards, or a company. It requires insert and search.

Which means this function is a vector store:

import numpy as np

ids = ["doc1", "doc2", "doc3"]
matrix = np.array([[0.1, 0.8], [0.9, 0.2], [0.4, 0.6]])

def nearest(query_vec, k=2):
    scores = matrix @ query_vec / (
        np.linalg.norm(matrix, axis=1) * np.linalg.norm(query_vec)
    )
    top = np.argsort(scores)[-k:][::-1]
    return [ids[i] for i in top]

Cosine similarity by brute force across every row. It is correct, it takes thirty seconds to build, and at small scale it outperforms every fancy alternative on latency because there is no network hop. Its weakness is arithmetic, not concept: scanning every vector per query grows linearly, so brute force dies somewhere past hundreds of thousands of items. The capability was always there; only the efficiency was missing.

A Vector Database Is a Product#

A vector database packages that capability into something survivable in production. The packaging typically includes approximate-nearest-neighbor indexes such as HNSW or IVF that answer queries without touching every vector, metadata filtering combined with similarity search, upserts and deletes that actually work, replication, access control, backups, and observability.

Two product categories sell this packaging. Dedicated engines like Pinecone, Qdrant, Milvus, and Weaviate are built around vectors as the primary data type. General-purpose databases bolted the capability on: Postgres through pgvector, Redis, Elasticsearch, OpenSearch, MongoDB Atlas. Both categories deliver the same underlying promise, which is exactly why marketing language sloshes between them.

Why the Distinction Decides Purchases#

Here is the practical payoff. If someone asks whether you need a vector database, the honest first response is another question: how many vectors, how fresh, filtered how hard?

Below roughly one hundred thousand vectors, pgvector or an embedded library covers nearly everyone, and your operational burden stays at whatever level Postgres already demanded of you. Dedicated engines earn their keep when datasets grow large enough that index management matters, write rates stay high, tail latency has contractual teeth, or multi-tenant filtering must combine with similarity search efficiently.

Vendors will happily let you skip those questions. Ask concrete ones instead: which index types are supported, what recall do filtered queries actually achieve, where do backups live, how does sharding work, and what happens if the company pivots? A product that cannot answer those is selling you the noun while you needed the operations.

Buy Operations, Not Nouns#

The phrase "vector database" names a purchase; the phrase "vector store" names a responsibility your system has regardless of what you buy. Your application needs the capability no matter what, and every option on the menu provides it. What differs is who worries about compaction, replication, failover, and index tuning: you, or a vendor whose invoice says you stopped worrying.

So start with the cheapest thing that answers nearest-neighbor queries correctly, usually numpy or pgvector, and keep retrieval behind one interface. When scale forces a real migration, the interface makes it a weekend project instead of a rewrite. Most teams discover their first thousand vectors never needed a database at all, just a function.