What Is a Vector Database?
A vector database is a database that searches by similarity in meaning instead of exact words. It stores embeddings – text turned into vectors – and quickly finds the ones closest to a query. That's why it's the hub of RAG solutions. Sometimes, though, a vector extension in the Postgres you already run is enough.
A vector database is a database built for a specific task: searching by similarity in meaning instead of exact words. That makes it the hub of most RAG solutions, where an AI is meant to answer based on your own documents. But that doesn’t mean everyone needs to get one – often what you already have is enough. Here’s what it does and when it’s needed.
Searching by Meaning, Not Exact Words
To understand a vector database, it helps to first understand what it stores: embeddings. An embedding is a text turned into a list of numbers, a vector, where texts with similar meaning get vectors that sit close together. A vector database specializes in storing such vectors and finding, at lightning speed, the ones closest to a given query.
The result is searching by meaning. If you ask about something to do with “bills,” the database can surface a document about “invoices,” because their vectors sit close together in meaning. The search is therefore about what the text means, not about which letters it happens to contain.
The Difference from a Regular Database Search
The clearest way to understand the value is to set it against a regular database. A traditional database is built for exactness: you ask for a customer number, a date, or an exact word, and it returns the rows that match precisely. That’s perfect when you know exactly what you’re looking for.
But it falls short when the question is about meaning. A concrete example: a user searches “how do I cancel my subscription.” A regular search misses a help article titled “end your contract,” since no words match. A vector database understands that the phrases mean the same thing and finds the right document anyway. One answers “where exactly is this?”, the other “what resembles this?”
Why It’s the Hub of RAG
RAG, retrieval-augmented generation, is built on a simple setup: before the language model answers, the documents relevant to the question are retrieved, so the answer is grounded in real text instead of the model’s memory. The decisive step is finding the right document – and that’s exactly what a vector database does.
It holds embeddings for all your documents and, for each question, pulls out the most relevant passages, quickly, even when the material is large. Without efficient similarity search, that step would become a bottleneck. So the vector database is rarely the part people talk about as the star, but it’s almost always what makes a RAG solution practically usable.
When Your Existing Postgres Is Enough
Here’s a useful bit of restraint: not everyone needs a specialized vector database. For smaller data volumes, it’s often plenty to add vector support to a database you’re already running.
The most common example is pgvector, an extension that gives PostgreSQL the ability to store and search vectors. If you’re already running Postgres, you can often start there, with no new infrastructure to manage. Other options, like Pinecone or Qdrant, are dedicated solutions that only become justified once the data volume and search-speed requirements grow large.
The advice is to start with what you have and upgrade once the need actually arises, not before. An extra database is also something that has to be run, monitored, and paid for.
What the Choice Really Comes Down To
Once the question of a dedicated vector database actually comes up, a few things decide it. Data volume is the clearest: a handful of documents makes no demands, but millions of passages mean search speed starts to matter. Response-time requirements are another – if the search needs to feel instant for a user in real time, that sets a higher bar than if it runs in the background.
Finally, your existing infrastructure carries a lot of weight. If you’re already running Postgres, the barrier to pgvector is low, while a fully cloud-based stack might fit better with a managed service. The point is to let the need drive the decision: choose based on data volume, performance requirements, and what you’re already running, rather than automatically reaching for the most specialized solution. Want help figuring out what’s enough for your specific solution? Read more about our work with AI or get in touch.
Frequently asked questions
What does a vector database do, simply put?
It stores text that's been turned into vectors, embeddings, and then looks for the vectors closest to a given query. In practice, that means it searches by meaning: it finds what resembles the query in content, even when the words aren't exactly the same. That's a completely different search principle from a regular database.
How does it differ from a regular database?
A regular database looks for exact values or word matches – rows that match precisely what you're asking for. A vector database looks for similarity in meaning and ranks results by how close they are to the query. So it answers 'what resembles this?' instead of 'where exactly is this?'.
Why is the vector database the hub of RAG?
Because RAG relies on finding the right document to give the language model before it answers, and that's exactly what a vector database is built for. It holds embeddings for all your documents and quickly pulls out the most relevant ones for each query. Without efficient similarity search, RAG would become slow and unreliable.
Do we need to get a dedicated vector database?
Not always. For smaller data volumes, it's often enough to add a vector extension to a database you already have, for example pgvector in Postgres. Only once volumes and search-speed requirements grow does a dedicated solution become justified. Start with what you have and upgrade once the need is proven, not before.
What alternatives exist?
Some common names are pgvector, which gives Postgres vector search, along with dedicated services like Pinecone and Qdrant. Which one fits depends on data volume, performance requirements, and what the rest of your infrastructure looks like. The point is to choose based on need rather than automatically reaching for the most specialized solution.