Definition
A vector database stores embeddings and answers a different question than a traditional database: not "which rows match this value" but "which items are most similar to this one." It is the retrieval engine underneath semantic search and most RAG systems.
What a vector database is for
A traditional database answers questions with exact criteria: customers in Quebec, orders over $500, tickets opened last week. It is precise, and it has no notion of similarity.
A vector database answers "what is most like this?" Give it the embedding of a question and it returns the passages whose meaning sits closest. That is a fundamentally different operation, and doing it quickly across millions of items is the engineering problem these systems exist to solve.
In a RAG system, this is the component that decides what the model gets to read. Its quality caps the quality of every answer downstream.
Do you actually need one?
Frequently not, and the honest answer saves real money.
For a few thousand documents, similarity search over embeddings held in memory or in a normal database runs fast enough that a specialized system adds operational overhead without adding capability. Postgres with the pgvector extension handles a surprisingly large range of business use cases, with the significant advantage that your vectors live beside your relational data and inside your existing backup and access-control regime.
A dedicated vector database starts earning its keep at genuine scale, meaning millions of vectors, high query concurrency, and frequent updates, or when you need features like distributed indexes and sophisticated filtering that general-purpose databases handle awkwardly.
The question worth asking is not "which vector database" but "does this need to be a separate system at all."
What matters more than the choice of engine
Metadata filtering. Almost every real query is "similar to this, and from the current policy version, and visible to this user." A system that cannot filter efficiently alongside the similarity search will either be slow or return things it should not. This is where permission enforcement actually lives.
Update behaviour. Documents change. How fast does the index reflect an edit, and what happens to the stale version? Systems that were only tested on a static corpus tend to get this wrong.
Hybrid search. Business queries mix concepts with identifiers. If the engine cannot combine keyword and vector search, you will end up building that layer yourself.
Portability. Embeddings are tied to the model that produced them, and models get replaced. Being able to rebuild the index from source content, rather than treating the database as the only copy, is what keeps a migration from becoming a rewrite.
How Automathing approaches it
We start with the simplest storage that meets the requirement, which for most mid-sized businesses means vectors alongside relational data rather than a separate system to run and secure. Permission filtering is designed into retrieval from the beginning rather than layered on later, and the source content always remains the system of record so the index can be rebuilt at will.
Frequently asked questions
What is the difference between a vector database and a regular database?
A regular database finds exact matches on values you specify. A vector database finds nearest neighbours in meaning-space, meaning the items most similar to a reference. They answer different questions, and many systems need both: the vector search to find relevant content, the relational data to know who is allowed to see it.
Can we just use Postgres?
Often, yes. The pgvector extension adds vector similarity search to Postgres, which is enough for a great many business applications and keeps everything in one system you already operate, back up, and secure. Reach for a dedicated vector database when scale, concurrency, or specialized indexing genuinely demands it.
How large can a vector database get?
The storage itself is manageable, since a million chunks with typical embedding dimensions is measured in gigabytes. What grows harder is query latency under concurrency and keeping the index fresh as documents change. Those operational concerns usually force the architecture decision well before raw storage does.
Does the vector database store our actual documents?
Typically it stores the embeddings plus the text chunk and metadata, so the retrieved passage can be shown to a user or passed to a model. That makes it a copy of your content requiring the same access controls, retention policy, and privacy treatment as the original source.