What Is Vector Database?
Also known as: Vector Store, Vector Search Engine
Definition
A vector database is a system that stores high-dimensional embedding vectors and retrieves the ones most similar to a query vector, enabling semantic search where results match meaning rather than exact keywords.
Vector Database Explained
Comparing a query vector against every stored vector is exact but scales linearly, which becomes impractical past a few hundred thousand records. Vector databases instead use approximate nearest neighbor indexes. HNSW builds a navigable multi-layer graph and walks it greedily from a coarse layer down to fine ones. IVF partitions the space into clusters and searches only the nearest few. Both trade a small amount of recall for order-of-magnitude speed gains, with tunable parameters that let you set that balance explicitly.
Metadata filtering matters as much as similarity in enterprise use. Every chunk should carry attributes such as document type, site, effective date, revision, classification level, and owning department. A query then combines vector similarity with a structured filter, so a search restricted to current-revision quality procedures for one plant never surfaces a superseded document from another. Databases differ meaningfully in whether filtering happens before, during, or after the vector search, and that choice affects both recall and latency.
The options span a wide range. Purpose-built engines such as Qdrant, Weaviate, and Milvus offer rich filtering, hybrid search, and horizontal scaling. Extensions to existing databases, notably pgvector for PostgreSQL, let you keep vectors next to relational data and reuse backup, replication, and access control you already operate. Embedded libraries such as FAISS or Chroma suit small single-node deployments. For on-prem work the deciding factors are usually operational fit and licensing rather than raw benchmark throughput.
Two operational realities catch teams out. First, embeddings are model-specific: change the embedding model and every stored vector must be regenerated, because vectors from different models are not comparable. Plan reindexing as a routine maintenance operation, not an emergency. Second, index memory footprint is substantial. HNSW graphs commonly consume well beyond the raw vector data itself, so a corpus of a few million chunks can require tens of gigabytes of RAM to serve at low latency.
Why It Matters
- Provides the retrieval layer every RAG deployment depends on, making it the component that most directly determines answer quality.
- Supports metadata filters that enforce plant, revision, and classification boundaries so users retrieve only documents they may see.
- Choice of engine determines whether you inherit new infrastructure to operate or extend a PostgreSQL instance your DBAs already run.
- Embedding model changes force a full reindex, so the migration path should be designed before the first corpus is loaded.
In Practice
A quality team indexed every revision of every work instruction without a revision field in the metadata. Semantic search happily returned superseded procedures alongside current ones, and the model cited them with equal confidence. The fix was not a better model but a metadata filter restricting retrieval to the active revision.
Frequently Asked Questions
Do I need a dedicated vector database or can I use PostgreSQL?
For corpora up to roughly a few million chunks, pgvector on PostgreSQL is usually sufficient and far simpler to operate, because it inherits your existing backup, replication, monitoring, and access control. Dedicated engines earn their operational cost at larger scale, with heavy concurrent query load, or when you need advanced hybrid search and reranking built into the retrieval layer.
How much storage does a vector database need?
Raw vectors are predictable: a 1024-dimension float32 embedding is about 4 KB, so one million chunks is roughly 4 GB of vector data plus the original text. The larger cost is the index. Graph indexes such as HNSW add substantial memory overhead on top of the vectors, so plan RAM capacity from the index footprint rather than from the vector size alone.
Related Terms
Embedding
An embedding is a list of numbers, typically several hundred to a few thousand dimensions, that represents the meaning of a piece of text, image, or code so that semantically similar items produce vectors that sit close together.
RAG (Retrieval-Augmented Generation)
RAG (Retrieval-Augmented Generation) is an architecture that searches your own document store for passages relevant to a question, inserts them into the LLM prompt, and instructs the model to answer only from that retrieved evidence.
On-Prem AI
On-prem AI is the practice of running artificial intelligence models on hardware you own and control, inside your own data center or plant, so prompts, documents, and model weights never leave your network.
Go Deeper
Manufacturing AI Readiness Assessment
Score your manufacturing operation's readiness for AI across data, systems, people, and governance, and get a prioritized roadmap for closing the gaps.
On-Prem LLM Deployment Architecture: Reference Guide
Reference architecture for on-prem LLM deployment: inference servers, GPU sizing, RAG pipelines, and security zones for regulated manufacturers.
Air-Gapped LLM Deployment Patterns That Actually Work
Air-gapped LLM deployment patterns that work: offline model transfer, update workflows, monitoring without telemetry, and CMMC-ready architectures.
Working with Vector Database in a live environment? Our engineers do this every day - and our AI agents automate most of it.