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

Quick answer: a vector store is any component that saves embeddings and returns the ones closest to a query. A vector database is a dedicated database server built around that job, with persistence, filtering, replication and access control. Every vector database is a vector store, but most vector stores are not databases.

If you only remember one thing: "vector store" describes what something does, "vector database" describes what something is.

Why the Terms Get Mixed Up

Most developers meet the phrase "vector store" in LangChain or LlamaIndex docs. In LangChain, VectorStore is an abstract interface. Anything that implements add_documents and similarity_search counts, whether it's a Python list in memory or a Pinecone index on the other side of the internet. LlamaIndex uses the same idea.

So when a tutorial says "pick a vector store," it means "pick something that implements this interface." Some options are libraries, some are Postgres extensions, some are full databases. The word covers all of them.

Then OpenAI added "vector stores" to its API for file search: you upload files, OpenAI chunks and embeds them, and the assistant retrieves from them. That's a managed vector store too, but it's neither a library nor a database you query directly.

Vendors add to the confusion. A database company will call its vector feature a "vector store" to sound lightweight, and a vector database company will call its product a "vector store" because that's what the LangChain integration page says. Same words, different things.

What Counts as a Vector Store

A vector store has two jobs:

1. Keep a set of embeddings, each tied to an ID and usually some metadata.
2. Given a query embedding, return the closest ones by cosine similarity, dot product or Euclidean distance.

Anything that does both is a vector store. Common examples, from lightest to heaviest:

• In-memory store. A list of vectors in your process. Exact nearest-neighbor search by brute force. Gone when the process restarts. Fine for a demo with a few thousand chunks.
• FAISS. A library from Meta for fast similarity search. It builds approximate nearest neighbor (ANN) indexes in memory and can write them to disk. It's a library, not a server: no API, no auth, and you handle metadata and updates yourself.
• Chroma (embedded mode). Runs inside your Python process and persists to a local directory. Easy to start with, and it can also run as a separate server once you outgrow that.
• pgvector. A Postgres extension that adds a vector column type plus HNSW and IVFFlat indexes. Your vectors live next to your rows, and you query them with SQL. It's a vector store inside a general-purpose database, sometimes called a "vector-capable database."
• A vector database. Pinecone, Qdrant, Weaviate, Milvus. Also a vector store, just a much bigger one.

What Makes Something a Vector Database

A vector database is the far end of that list. It's a database server whose main job is storing and querying vectors, and it adds the things you'd expect from any production database:

• Durability. Writes survive crashes. Data is replicated.
• Real-time updates. Insert, update and delete vectors without rebuilding the index from scratch.
• Filtered search. "Nearest vectors where category = 'shoes' and price < 100," handled inside the index so filters don't wreck recall.
• Horizontal scale. Sharding across nodes once one machine isn't enough.
• Access control and multi-tenancy. API keys, namespaces or collections per customer.
• Operational tooling. Backups, monitoring, snapshots.

That's what you pay for, either in a managed bill (Pinecone, Qdrant Cloud, Zilliz) or in engineering time if you self-host. We broke down that second cost in The Hidden Costs of Self-Hosting Your Vector Database.

Vector Database vs Vector Search Library

This is the same question from a different angle. FAISS, Annoy, ScaNN and hnswlib are vector search libraries: they implement ANN algorithms and nothing else. A vector database usually runs one of those same algorithms (HNSW is the most common) and wraps it in storage, an API, filtering and replication.

If your data fits in memory on one machine, rarely changes, and you're fine rebuilding the index on deploy, a library is often enough. Once you need live updates, filters and more than one machine, you're rebuilding a database by hand, and you should use one.

Vector Database vs a Database With Vector Search

The third option, and the one most teams should look at first, is the database you already run. Postgres has pgvector. MongoDB Atlas, Elasticsearch, OpenSearch and Redis all have vector search built in.

The big advantage is that you don't have a second copy of your data to keep in sync. With a separate vector database, every product edit, deleted document or permission change has to go to two places. Sync bugs are the most common reason teams see stale or "ghost" results in production. With vectors in the same database, one transaction updates both.

The trade-off is performance at the high end. A dedicated vector database is usually faster at large scale and with heavy filtering. Our pgvector vs Pinecone vs Qdrant benchmark shows where that line falls in practice. For most apps under a few million vectors, pgvector is fast enough.

How to Choose

Start with the smallest thing that works, and move up only when you hit a real limit.

Use an in-memory store or FAISS if:

• You're prototyping or running a notebook
• The dataset is small and mostly static
• Losing the index on restart is fine

Use pgvector (or your existing database's vector search) if:

• You already run that database
• You have up to a few million vectors
• You want vectors and records updated together, with no sync job

Use a dedicated vector database if:

• You have tens of millions of vectors or more, or high query volume
• You need heavy metadata filtering at low latency
• You have people to own it, or a budget for a managed tier

Use a managed search API if:

• What you actually want is search, not vectors
• You don't want to pick embedding models, build an ingestion pipeline or keep two systems in sync
• You need image search, OCR or multilingual search alongside text

That last option is worth thinking about before you choose any of the others. Every vector store and vector database still needs you to generate embeddings, store the source records somewhere, and wire the two together. That's most of the work. We covered this in more depth in Do You Need a Vector Database? Probably Not.

Where Vecstore Fits

Vecstore isn't a vector store or a vector database in the sense above. You don't send it vectors. You send it your text, images or both, and query in plain language or with an image. Embeddings, indexing, ranking and model upgrades happen inside.

curl -X POST https://api.vecstore.app/api/databases/{db_id}/search \
  -H "X-API-Key: $VECSTORE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "waterproof hiking boots under $150"}'

There's no embedding pipeline to build and no second database to keep in sync. The same database handles semantic text search, reverse image search, OCR search and NSFW detection.

If you need to control the vector layer directly (custom embedding models, your own reranking, research workloads), use a vector database. If you need search that works in your product, start with a search API.

FAQ

Is a vector store the same as a vector database?

No. A vector store is anything that stores embeddings and returns the nearest ones to a query, including in-memory lists, FAISS indexes and pgvector columns. A vector database is a dedicated server built for that job, with persistence, filtering, replication and access control. Every vector database is a vector store, but not the other way around.

Is Pinecone a vector store or a vector database?

Pinecone is a vector database. LangChain and LlamaIndex list it as a "vector store" because it implements their vector store interface, which is where the mixed naming comes from.

Is FAISS a vector database?

No. FAISS is a vector search library. It builds fast nearest-neighbor indexes in memory, but it has no server, no built-in persistence layer beyond saving an index file, and limited metadata filtering. Vector databases often use the same kinds of algorithms underneath.

Is pgvector a vector database?

pgvector is an extension that turns Postgres into a vector-capable database. It stores vectors next to your regular rows and supports HNSW and IVFFlat indexes. For most apps under a few million vectors it's enough, and it avoids running a separate vector database.

What is an OpenAI vector store?

It's a managed store in the OpenAI API used for file search. You upload files, OpenAI chunks and embeds them, and models retrieve from them during a response. It's convenient for assistants that answer questions from documents, but you don't control the embeddings or query it like a general search index.

How do I avoid syncing data between my database and a separate vector store?

Keep vectors in the same database as your records (pgvector, MongoDB Atlas Vector Search, Elasticsearch), or use a search API that stores both the records and the index together. Either way, one write updates everything, so there's no sync job to break.

When do I actually need a vector database?

When you have tens of millions of vectors or more, need low-latency search with heavy filtering, or run high query volume, and you have the people or budget to operate it. Below that, a vector store inside your existing database or a managed search API is usually simpler and cheaper.

Try Vecstore free or read the API docs.