A vector database is a database that stores meaning as numbers. It converts text, images, or records into embeddings, which are long lists of numbers, and then finds results by similarity. You ask it for whatever is closest in meaning, not for an exact match on a value.
That one difference changes how search behaves. A regular database can tell you whether two company names are identical. By contrast, a vector database can tell you that two different spellings probably describe the same company, even when the strings share almost nothing.
I have run a local vector store for content analysis since 2024, and I have watched teams both overuse and underuse this technology. Honestly, the concept is simpler than the hype suggests. In this entry, I will explain embeddings without math, compare the main products, cover real costs, and tell you when a plain relational database is still the better choice.
What Does a Vector Database Actually Store?
A vector database stores embeddings, which are numeric fingerprints of meaning produced by a machine learning model. Each embedding is an ordered list of numbers, usually several hundred to a few thousand of them. IBM’s overview describes these vectors as mathematical representations of data in a high-dimensional space.
Ignore the jargon for a second. Here is the analogy I use with non-engineers: an embedding is a set of GPS coordinates for meaning. Paris and Rome sit near each other on a map of cities. In the same way, “CEO” and “chief executive” sit near each other on a map of language, while “CEO” and “forklift” sit far apart.
The model that draws this map was trained on huge amounts of text, so nearness reflects how words are actually used. Google’s machine learning crash course has a friendly visual walkthrough if you want to see the idea in pictures. The vector database itself does not create embeddings. It stores them, indexes them, and answers one question fast: which stored items sit closest to this one?
This is also why the technology matters for messy content. Emails, call notes, PDFs, and web pages are all unstructured data. Rows and columns handle that material badly. Coordinates on a meaning map handle it naturally.
One more thing before we move on: embeddings are not limited to text. Models exist for images, audio, and even product catalogs, and they all produce the same kind of number list. That shared format is why one database design can serve photo search, voice matching, and document retrieval alike.
📌 Example: The phrases "VP of Marketing" and "marketing vice president" share one word. Their embeddings sit almost on top of each other. A keyword search treats them as different strings; a vector search treats them as the same job. That closeness is the entire trick.
Where Did Vector Databases Come From?
Vector databases grew out of decades-old nearest neighbor research, matured as internal tools at big tech companies, and became products once AI made embeddings mainstream. The category feels brand new. Its parts are not.
Search and recommendation teams at large companies were running similarity search internally long before anyone sold it. A visible turning point came in 2017, when Meta’s research lab open-sourced FAISS, a library for fast similarity search over millions of vectors. Suddenly any engineer could experiment with the technique on a laptop.
Dedicated products followed. Milvus went open source in 2019, the same year Pinecone was founded to sell vector search as a managed service. Around 2021, Qdrant and Weaviate gained traction, and pgvector quietly brought the capability into PostgreSQL. These were still niche tools for search specialists.
Then late 2022 happened. ChatGPT made every company want AI features grounded in its own documents, and RAG became the standard recipe for that. Vector databases were the missing ingredient, so 2023 brought a funding wave, loud marketing, and a crowded market. The correction since has been healthy: general databases absorbed vector features, and the dedicated engines refocused on scale. Knowing that arc helps you read vendor claims with the right skepticism.
How Does Similarity Search Actually Work?
Similarity search works by measuring the distance between number lists and returning the records whose numbers sit closest to your query. No matching on words happens at all. The comparison runs purely on the coordinates.
The most common distance measure is called cosine similarity. You do not need the formula. It simply scores how strongly two embeddings point in the same direction, from around zero for unrelated content up to one for nearly identical meaning. In my own content work, pairs above 0.85 are usually the same topic in different words.
Checking your query against every stored vector would be painfully slow at scale. So vector databases build approximate nearest neighbor indexes, ANN for short, which skip most of the comparisons. The popular ones, like HNSW, organize vectors into a graph of shortcuts. Pinecone’s explainer covers these index types in plain language if you want one level deeper.
The full loop looks like this in practice:
- Embed once, store once. Every document or record goes through the embedding model, and the resulting vector lands in the database.
- Embed the query. When someone searches, their question goes through the same model and becomes a vector too.
- Find the neighbors. The ANN index returns the stored vectors that sit nearest to the query vector.
- Return ranked results. Each match comes back with a similarity score you can filter or threshold.
Real systems add one more ingredient: metadata filters. Every vector can carry plain fields like language, date, or record type. A query then reads “find the nearest neighbors, but only among English pages from this year.” Without that filtering, similarity search returns beautiful matches from all the wrong places.
One honest caveat belongs here. The word “approximate” is doing real work in ANN. These indexes trade a small slice of accuracy for enormous speed. In most applications that trade is invisible. For compliance searches where missing one record matters, it is not, and you should know that going in.
Vector Database vs Relational Database vs Search Index: What Is the Difference?
The difference comes down to the question each system answers best. A relational database answers “give me records where this value equals that.” A keyword search index answers “give me documents containing these words.” A vector database answers “give me whatever means roughly this.”
People often lump vector databases in with NoSQL systems, since neither uses tables as the primary shape. That grouping is fair but incomplete. The Wikipedia entry on vector databases treats them as their own category, and I agree, because the query model is genuinely different from anything else.
| Question | Relational database | Keyword search index | Vector database |
|---|---|---|---|
| What it stores | Rows and columns | Documents and word positions | Embeddings plus metadata |
| How it matches | Exact values and ranges | Word overlap and relevance scoring | Distance between vectors |
| Typical query | Deals over 20k closing this month | Pages containing “pricing plan” | Content similar to this paragraph |
| Great at | Transactions, joins, reporting | Fast text lookup, filters, facets | Synonyms, paraphrase, fuzzy meaning |
| Weak at | Fuzzy or semantic questions | Different words, same meaning | Exact values, joins, transactions |
| Examples | PostgreSQL, MySQL | Elasticsearch, OpenSearch | Pinecone, Qdrant, Milvus |
Notice that no column wins every row. That is the real lesson of the table. These systems are complements, not rivals, and mature stacks usually run at least two of them side by side.
💡 Pro Tip: The best production search is usually hybrid: a keyword index for precision on names and codes, plus a vector search for meaning, with results merged. If a vendor tells you vectors alone will handle part numbers and invoice IDs, walk away slowly.
Who Are the Main Vector Database Players?
The names you will meet first are Pinecone, Weaviate, Qdrant, Milvus, and pgvector, and each makes a different trade-off between convenience and control. All five are capable. What separates them is how much operations work you are willing to own.
| Product | What it is | Strength | Trade-off |
|---|---|---|---|
| Pinecone | Fully managed cloud service | Zero operations, fast to start | Closed source; costs climb with scale |
| Weaviate | Open-source database with modules | Built-in hybrid search and integrations | More moving parts to learn and run |
| Qdrant | Open-source engine written in Rust | Strong metadata filtering, generous free tier | Smaller ecosystem than the giants |
| Milvus | Open-source system for massive scale | Handles billions of vectors | Heaviest to deploy and operate |
| pgvector | Extension inside PostgreSQL | Lives in the database you already run | Slower once vectors reach the tens of millions |
A few honest notes on that table. pgvector is a free extension, not a separate product, and for many teams it quietly ends the shopping trip. Qdrant’s own explainer is unusually candid about when you do not need them. Meanwhile, Weaviate’s material is the best place to understand hybrid search as a first-class feature.
Every option here exposes an API, so switching later is annoying but rarely catastrophic. My advice is boring on purpose: pick by your operations capacity, not by benchmark charts. Benchmarks measure the vendor’s tuned setup, not the one your team will actually maintain at 2 a.m.
What Do Vector Databases Power?
Vector databases power retrieval-augmented generation, semantic search, record matching, and recommendation engines. AWS lists the same core use cases, and the pattern behind all four is identical: find the nearest neighbors, then act on them.
Retrieval-augmented generation, or RAG, is the headline act right now. An AI assistant embeds your question, pulls the closest passages from your own documents, and writes its answer from those passages. The vector database is the lookup layer that keeps the model grounded in your content instead of its imagination.
Semantic search is the same machinery pointed at people. A visitor types “how do I fix billing,” and results about invoice errors appear even though no page contains that exact phrase. This works because modern natural language processing models capture intent, not just vocabulary.
Then comes the unglamorous pair I care about most. Fuzzy deduplication finds near-identical records that string comparison misses. Recommendations do the same for products and content: people who engaged with this vector tend to engage with its neighbors.
🔍 Field Note: A six-person SaaS team I advised in 2025 wired 400 help articles into a RAG assistant over a weekend. Deflection looked great until we checked answers: about one in five cited the wrong article version. The fix was not a better model. It was deleting 90 outdated docs before re-embedding.
Why Should B2B Data Teams Care About Vector Databases?
B2B teams should care because company and contact records almost never match exactly, and vectors match by meaning instead. Your CRM says “IBM.” The signup form says “International Business Machines Corp.” A conference list says “I.B.M. Deutschland.” Classic data matching rules need endless hand-written exceptions for cases like these. Embeddings place all three names in the same neighborhood automatically.
Job titles benefit even more. “Head of Growth,” “VP Marketing,” and “Demand Gen Lead” are different strings doing similar jobs. Semantic matching groups them for segmentation without a 2,000-row mapping table. Some B2B data enrichment providers, CUFinder included, use this kind of matching internally to link messy CRM names to real company records. That said, no matching model saves a pipeline nobody samples by hand; you still have to spot-check pairs before trusting them.
Content teams get a quieter win: gap analysis. In 2026 I embedded 1,267 of our own pages and 494 pages from one strong competitor into a local vector store. Ranking our weakest similarity scores against their coverage surfaced two dozen topics we had simply never written about. The whole analysis cost one evening and a few dollars in embedding fees.
None of this requires big data infrastructure, by the way. A few thousand company records embed in minutes on a laptop. The barrier here is evaluation discipline, not compute.
How Do You Start a Vector Search Project? A First-Week Plan
Start a vector search project by writing your test queries before you touch any infrastructure. That single habit separates projects that work from demos that impress and then quietly fail. Here is the five-day plan I run with teams doing this for the first time.
- Day 1: define the question and the corpus. Write one sentence describing what “similar” means for your use case, then gather the documents or records it applies to.
- Day 2: build a test set. Collect 20 to 50 real queries with the answer each one should return. Pull them from support tickets, search logs, or teammates, not from your imagination.
- Day 3: chunk and embed. Split long documents into passages of a few hundred words, run them through one mainstream embedding model, and store the results.
- Day 4: wire the smallest search loop. Load vectors into pgvector or an in-memory library and return the top five neighbors for a query. Resist buying anything yet.
- Day 5: measure and tune. Score every test query, then adjust chunk size or the model based on misses. Only a passing test set earns a conversation about dedicated databases.
Notice what is missing from that week: product selection. Vendor choice is genuinely the least important decision in the project, because a pipeline that fails on pgvector will fail identically on the most expensive managed service. Retrieval quality lives in the data and the chunking, not in the engine.
📌 Checkpoint: If fewer than 70 percent of your test queries return a correct result in the top five, stop. Fix the chunking, the embedding model, or the corpus before any infrastructure discussion. In my experience, the corpus is the culprit twice as often as the model.
When Do You Not Need a Vector Database?
You do not need a vector database when your data is small, your questions are exact, or your existing PostgreSQL can carry the load. This section exists because vendors will not write it, and I have watched teams buy infrastructure for problems a spreadsheet could solve.
Start with size. Under roughly 100,000 vectors, a plain in-memory library computes exact similarity in milliseconds. My own content store holds fewer than 2,000 embeddings in a single SQLite file, and queries finish before my finger leaves the Enter key. A dedicated database would add cost and moving parts for nothing.
Next, check the question. Order lookups, email deduplication on normalized strings, and ID joins are exact-match problems. Vectors make those worse, not better, because “approximately this invoice number” is never what anyone wants.
Finally, respect the pgvector case. If you already run PostgreSQL and expect fewer than a few million vectors, the extension gives you similarity search inside the database you already back up and monitor. Plenty of production RAG systems run on exactly that and nothing more.
🧠 Worth Remembering: Buy a dedicated vector database when similarity search is a core product feature at real scale. Until that day, a Postgres extension or an in-memory library is the honest answer, and your future self will thank you for the smaller bill.
How Much Does a Vector Database Cost?
Vector database costs range from free to thousands of dollars per month, and the database is rarely the biggest line. Managed services typically start with a free tier, then move into paid plans as vectors and queries grow. Self-hosted options are free as software but cost servers, memory, and someone’s attention.
Some rough bands help with planning. Free tiers on the managed services comfortably hold a prototype with a few hundred thousand vectors. Entry paid plans tend to land in the tens of dollars per month, while serverless pricing bills you separately for storage, writes, and reads. On the self-hosted side, a few million vectors fit on one modest server, and the real spend is the engineer who keeps it healthy.
Memory deserves special mention. ANN indexes live largely in RAM for speed, so a hundred million vectors translates into serious hardware whichever route you choose. Below a million vectors, honestly, almost any option is cheap.
Budget for three quieter items too. Embedding models charge per token, so the first full load of a large corpus is a real bill. Re-embedding is the trap: switch embedding models and every stored vector must be regenerated, because vectors from different models do not mix. And evaluation time is a labor cost that never appears on any invoice.
The market itself is growing fast, which explains the noise around the category. MarketsandMarkets projects the vector database market to grow from 2.65 billion dollars in 2025 to 8.95 billion by 2030, a 27.5 percent yearly rate. Fast-growing markets attract loud marketing, so price the whole workload, not the sticker.
What Are the Most Common Vector Database Mistakes?
The most common mistakes are skipping evaluation, guessing at chunk sizes, and treating the vector database as a system of record. I have made two of these three myself, so this section comes from scar tissue rather than theory.
Skipping evaluation is the big one. In 2024 I shipped a semantic search that looked brilliant in demos. When we finally built a 50-query test set, nearly a third of top results were topically wrong, and nobody had noticed because demo queries were always friendly. Twenty labeled queries before launch would have caught it. Build that tiny test set first; it is an afternoon of work.
Chunk size is the quiet killer in RAG systems. Embed whole pages and every vector becomes a blurry average of ten topics, so matches feel vaguely related but useless. Slice too fine, down to single sentences, and you lose the context instead. Most teams land somewhere around a few hundred words per chunk with some overlap, but the honest answer is to test against your own queries.
The third mistake is architectural. A vector database is not your source of truth. It has no real joins, weak transactions, and an index that is intentionally approximate. Keep the authoritative records in your regular database, treat the vector side as a rebuildable index, and mind data quality upstream. Embedding a duplicate-riddled dataset just gives you fuzzy search over garbage.
Frequently Asked Questions
What is an example of a vector database?
Pinecone, Weaviate, Qdrant, and Milvus are the best-known dedicated vector databases. pgvector is a popular alternative that adds vector search inside PostgreSQL. Many general platforms, including Elasticsearch, MongoDB, and Redis, now offer vector search as an added feature rather than a separate product.
What is the difference between SQL and a vector database?
SQL databases match exact values and ranges on structured columns, such as all deals above a threshold. A vector database matches by meaning, returning the records whose embeddings sit closest to your query. SQL answers precise questions; vectors answer similarity questions. Most production systems run both together.
Is MongoDB a vector database?
Not primarily. MongoDB is a document database, but its Atlas Vector Search feature adds embedding storage and similarity queries. The same pattern applies across the industry: many established databases have bolted on vector search. For moderate workloads these add-ons are fine, while dedicated engines still lead at large scale.
What is the vector in a vector database?
The vector is the embedding itself: an ordered list of numbers, commonly between 384 and 3,072 values, produced by a machine learning model from your text or image. Items with similar meaning get numerically similar vectors. The database indexes those lists so it can find nearest neighbors quickly.
Do I need a vector database for RAG?
Not always. A small document set can live in memory or in PostgreSQL with pgvector, and many production RAG systems run exactly that way. You need a dedicated vector database when the corpus is large, updates constantly, or must serve many concurrent queries with low latency.
Can PostgreSQL work as a vector database?
Yes. The open-source pgvector extension adds a vector column type, similarity operators, and ANN indexes to PostgreSQL. It comfortably handles workloads up to a few million vectors for most teams. Beyond that range, or under heavy query concurrency, dedicated engines usually deliver better speed and recall.
Is a vector database the same as a vector store?
Mostly, yes. People use the terms interchangeably, and this page does too. When a distinction is drawn, a vector store means a lightweight component inside an application framework, while a vector database means a full standalone server with indexing, filtering, persistence, and scaling features.
Are vector databases replacing relational databases?
No. They answer different questions. Relational databases remain the system of record for transactions, joins, and reporting. Vector databases add a similarity layer on top for search, matching, and AI retrieval. The realistic future is both running side by side, often with keyword search as a third partner.
So that is a vector database in plain terms: a map of meaning, an index that finds neighbors fast, and a tool that rewards teams who test before they trust. Start with the smallest option that answers your question, measure results against real queries, and scale up only when the numbers demand it. Boring discipline beats exciting infrastructure in this field, and it always will.
Bad
Okay
Good
Amazing
