A vector database is a system that stores vector embeddings and retrieves the ones closest in meaning to a query vector. It uses approximate nearest neighbor indexing to return results in milliseconds across millions of vectors. In commercial real estate, a vector database makes semantic search over leases, rent rolls, and offering memorandums fast enough to use.
How Does a Vector Database Work?
A vector database works by indexing embeddings so the nearest vectors to a query can be found without comparing against every stored vector. A brute-force scan computes distance to all vectors, so its cost grows linearly, O(n), with the count. A vector database instead builds an index, most commonly HNSW, that reaches logarithmic-scale search time and skips most comparisons.
HNSW, Hierarchical Navigable Small World, builds a layered graph of vectors and navigates from coarse top layers to fine lower layers, so search cost scales logarithmically with the number of vectors rather than linearly, per the original Malkov and Yashunin paper and vector-database documentation. That structure is why a well-tuned vector database answers a query over ten million vectors in single-digit to low-tens-of-milliseconds latency, per published benchmarks such as Pinecone's reported figures.
Component | Function |
Embeddings | Numeric vectors representing document passages |
Index (HNSW) | Graph structure enabling approximate nearest neighbor search |
Similarity metric | Cosine or dot product used to score closeness |
Metadata store | Filters results by document type, date, or property |
Query engine | Embeds the query and returns the top nearest vectors |
Why a Vector Database Matters
A vector database matters because scale makes brute-force search unusable. Searching a query against every vector in a large lease and offering-memorandum corpus is linear work, so latency climbs with the document count. Approximate nearest neighbor indexing holds latency roughly flat as the corpus grows, which is what lets semantic search stay interactive on a real deal room.
The tradeoff is recall for speed. An approximate index may miss a small fraction of true nearest neighbors, so vector databases expose recall as a tunable measure, and reported systems commonly target recall of 0.95 or higher, per vendor benchmarks such as Weaviate's ANN benchmark. The working principle is direct: a vector database trades a sliver of exactness for search that stays fast as the document set grows.
Example
A vector database earns its place at scale. A firm indexes 5 million passages from its lease and offering-memorandum archive. Each passage is a 1536-dimension embedding, and an analyst runs a semantic query.
Approach | Comparisons per query | Behavior |
Brute-force scan | 5,000,000 | Distance computed against every vector, linear cost |
HNSW index | A few thousand | Graph navigation skips most vectors, logarithmic-scale cost |
The brute-force scan computes 5 million distance calculations for a single query, and cost doubles if the archive doubles to 10 million. The HNSW index visits only a few thousand vectors by navigating the graph, returns the nearest passages in milliseconds, and its per-query work grows on a logarithmic scale as the archive expands. At a recall target of 0.95 it returns 19 of the true top 20 passages on average, which the analyst reviews.
Variations and Edge Cases
A vector database is a category with several designs, and the right one depends on scale, hosting, and index control. Some are purpose-built, others are extensions to an existing database. The variants below trade control and cost against operational simplicity.
Variant | Treatment |
Purpose-built (Pinecone, Weaviate, Qdrant, Milvus) | Optimized for vector workloads, often lowest latency |
Extension (pgvector) | Adds vectors to a relational database, simpler stack |
Index type | HNSW for speed, IVF or flat for exact recall on small sets |
Quantization | Compresses vectors to cut memory at a small recall cost |
Managed vs self-hosted | Managed hides index tuning; self-hosted exposes parameters |
Vector Database vs Relational Database
A vector database is often confused with a relational database, and the difference is what they search on. A vector database searches by similarity between embeddings and returns the nearest vectors by meaning. A relational database searches by exact matches and ranges on structured columns and returns rows that satisfy those conditions.
A relational database answers "which leases expire before 2027," a structured filter on a date column. A vector database answers "which clauses are about early termination," a similarity search over text meaning. CRE systems often use both: the vector database finds the relevant passages, and structured fields filter or join them.
Frequently Asked Questions
What is a vector database used for?A vector database stores embeddings and finds the ones closest in meaning to a query, which powers semantic search and retrieval-augmented generation. In commercial real estate it lets a system search leases, rent rolls, and offering memorandums by meaning at speeds that stay fast as the document count grows.
Why not just search embeddings without a vector database?Comparing a query against every stored embedding is linear work, so latency climbs as the corpus grows. A vector database uses approximate nearest neighbor indexing like HNSW to reach roughly logarithmic-scale search time, which keeps queries fast across millions of vectors.
What is HNSW in a vector database?HNSW, Hierarchical Navigable Small World, is a graph index that navigates from coarse to fine layers to find nearest vectors without scanning all of them. It gives search that scales on a logarithmic order with vector count, and it is the most common index in production vector databases.
Related Terms
Semantic Search
Retrieval-Augmented Generation
Structured Data Extraction
Document Extraction
Field Extraction