A RAG prototype usually starts with an in-memory vector store that lives inside the application process. When the prototype heads to production, a common next step is to add a standalone vector database next to the existing application database, plus a job that copies embeddings and metadata between the two. That second system brings its own scaling, backups, access control, and sync failures. The vector store vs vector database question decides whether you take on that second system at all.
This guide separates the two terms, lists the cases where a specialized vector database is worth it, and shows how a SQL database such as TiDB can sit behind the same vector store interface.
What Is a Vector Store?
A vector store is the layer that holds embeddings and returns the ones closest to a query vector. The term carries two meanings. In storage terms, it is the component that persists vectors and runs similarity search, whether that is an in-memory library, an extension inside a database, or a standalone service. In framework terms, LangChain and LlamaIndex each define a vector store interface that your RAG code calls, and many backends implement it.
The framework meaning is the one that matters for production planning. Your application code talks to the interface, so the real decision is which backend sits behind it and what else that backend has to do.
Vector Store vs. Vector Database: The Difference
A vector database is a full database system built around vector storage, adding durability, indexing, metadata filtering, and operational tooling to the core store. Every vector database contains a vector store, but not every vector store is a database.
| Dimension | Vector store (library or in-process) | Standalone vector database | SQL database with vector support |
|---|---|---|---|
| Examples | FAISS, in-memory Chroma | Pinecone, Weaviate, Qdrant, Milvus | PostgreSQL with pgvector, TiDB |
| Durability | Often none, or file snapshots | Built in | Built in |
| Metadata filtering | Basic, in application code | Vendor-specific filter syntax | Full SQL WHERE and joins |
| Transactions with app data | No | No; requires a sync job | Yes, same database |
| Scaling | Bounded by one process | Scales the vector workload | pgvector scales with its PostgreSQL instance; TiDB scales out storage nodes |
Image retrieval shows the difference in practice. A library can find visually similar images for a demo, but a production catalog also needs stock, price, and region filters, which live in the application database. An e-commerce recommendation engine has the same shape: the similarity search is the easy part, and keeping it consistent with inventory is the hard part.
For the broader comparison of vector databases against relational systems, see vector database vs traditional database.
When a Specialized Vector Database Makes Sense
A standalone vector database earns its operational cost when vectors are the workload rather than one feature of it. That usually means one of these:
- Your corpus has no meaningful relational data to join, such as a pure similarity service over images or audio.
- You need index types, quantization methods, or distance functions that your SQL database does not offer. TiDB, for example, indexes cosine and L2 distance with HNSW only.
- A separate team owns retrieval and wants to scale and tune it independently of the transactional database.
If none of those apply, a second database mostly adds a sync pipeline and another system to secure.
How TiDB Serves as a Vector Store Without a Separate Database
TiDB acts as the vector store backend by keeping embeddings in a VECTOR column of an ordinary table, so vectors, metadata, and transactions live in one MySQL-compatible database. TiKV stores the rows; TiFlash, the columnar engine, holds the HNSW index; and TiDB scales out by adding nodes rather than by moving to a bigger instance. A retrieval query can join the nearest neighbors to any other table in the same statement.
CREATE TABLE chunks (
id BIGINT PRIMARY KEY,
doc_id BIGINT,
content TEXT,
embedding VECTOR(3),
VECTOR INDEX idx_embedding ((VEC_COSINE_DISTANCE(embedding)))
);
-- Nearest chunks first, then join to document metadata
SELECT n.id, n.content, d.title, d.owner_team
FROM (
SELECT id, doc_id, content
FROM chunks
ORDER BY VEC_COSINE_DISTANCE(embedding, '[0.31, 0.62, 0.18]')
LIMIT 20
) AS n
JOIN documents d ON d.id = n.doc_id
WHERE d.status = 'published';The example assumes a documents table already exists and uses three dimensions for readability. Running the KNN step in a subquery keeps the vector index in play, because a WHERE filter applied before KNN skips it.
On the framework side, TiDB provides official LangChain and LlamaIndex integrations, so code written against either vector store interface can point at TiDB. Dify, the open-source LLM application platform, uses TiDB Cloud Starter as its vector store alongside its application data and consolidated nearly half a million database containers into a single TiDB Cloud implementation.
TiDB Cloud docs currently label vector search beta or preview, and Self-Managed docs mark it experimental for v8.4.0 and later. The TiDB vector search reference covers features, limits, and availability by tier.
FAQ
Short answers on vector stores, vector databases, and RAG backends.
Is a vector store the same as a vector database?
- No. A vector store holds embeddings and runs similarity search.
- A vector database wraps a vector store with durability, indexing, filtering, and operations tooling.
- In LangChain and LlamaIndex, “vector store” also names the interface your code calls.
Can a relational database act as a vector store?
- Yes. PostgreSQL does it with the pgvector extension, and TiDB does it natively with a VECTOR type and HNSW index.
- The benefit is SQL filtering and joins against the rows each embedding describes.
- Check which distance functions and index types each database supports before you commit.
Do I need a vector database for RAG?
- Not always. RAG retrieval typically combines vector search with metadata filters and permissions.
- If that metadata already lives in a SQL database with vector support, one system can serve both.
- A standalone vector database fits when retrieval is the whole workload or needs features SQL databases lack.
Run a Vector Store and Your Application Data on One TiDB Cloud Starter Cluster
If your embeddings describe rows you already store, a SQL database with vector support can be the vector store and skip the sync job entirely. Start a free TiDB Cloud Starter cluster and point your LangChain or LlamaIndex vector store at it. For more retrieval patterns, see vector search and RAG on TiDB.
