Vector Database Search System

1. Introduction

A vector database search system stores embeddings and retrieves nearby vectors quickly. It is the data infrastructure behind semantic search, recommendations, image search, document assistants, and many retrieval-augmented generation pipelines.

The naive implementation is:

store every vector in a table
compare the query vector to every stored vector
return the closest ones

That works for tiny datasets. It fails when the product has millions or billions of vectors, metadata filters, deletes, tenant boundaries, and strict latency targets. A production vector database is therefore a search-serving system, an indexing system, and an operational data system at the same time.

2. Product Requirements

Functional Requirements

• Store embedding vectors with stable IDs and payload metadata.
• Support similarity search by vector.
• Support metadata filters such as tenant, document type, timestamp, language, or visibility.
• Return top-k candidates with IDs, scores, and metadata.
• Support inserts, updates, deletes, and collection management.
• Support index rebuilds and embedding-version migrations.
• Provide observability for latency, recall, freshness, and index health.

Non-Functional Requirements

• Query latency should remain low as the collection grows.
• Search should preserve tenant and permission boundaries.
• Deletes should stop returning data according to product policy.
• Index builds should not make the service unavailable.
• The system should recover from durable source data.
• Memory and storage cost should be predictable.
• Recall and latency should be tunable for different workloads.

3. Core Engineering Challenges

The system becomes difficult because the search index is a derived structure. The durable truth may be documents, products, images, or chunks elsewhere. The vector database must keep its derived index close enough to that truth while serving live queries.

4. High-Level Architecture

flowchart LR
  Producer[Embedding producer] --> IngestAPI[Vector ingest API]
  IngestAPI --> WAL[(Durable write log)]
  WAL --> SegmentBuilder[Segment builder]
  SegmentBuilder --> VectorStore[(Vector storage)]
  SegmentBuilder --> IndexBuilder[Index builder]
  IndexBuilder --> ANNIndex[(ANN index)]
  QueryClient[Query client] --> QueryAPI[Query API]
  QueryAPI --> FilterEngine[Metadata filter engine]
  FilterEngine --> ANNIndex
  ANNIndex --> CandidateFetcher[Candidate fetcher]
  CandidateFetcher --> VectorStore
  CandidateFetcher --> QueryClient

The ingest path accepts vectors and metadata, writes durable intent, stores vector records, and updates index structures. The query path accepts a query vector and filters, searches the approximate index, hydrates candidates, and returns results. Background jobs compact segments, rebuild indexes, and handle deletes.

5. Core Components

Ingest API: validates vector dimensions, embedding version, collection name, tenant, and metadata schema.

Durable write log: records insert, update, and delete intent so the service can recover or rebuild derived indexes.

Vector storage: stores raw vectors and metadata. It may be columnar, segment-based, or database-backed depending on scale.

Metadata index: supports filters over tenant, timestamps, permissions, categories, and other fields.

ANN index: accelerates nearest-neighbor search. HNSW-style graph indexes are common for low-latency approximate search, though different workloads may choose other techniques.

Query planner: decides whether to pre-filter, search first then filter, use a filtered index, or fall back to exact search for tiny subsets.

Compaction and rebuild workers: merge segments, remove deleted records, rebuild indexes, and create new embedding-version collections.

Monitoring layer: tracks query latency, recall probes, index size, memory use, ingest lag, delete lag, and error rates.

6. Data Modeling

A vector record usually has this shape:

collection_id
record_id
tenant_id
embedding_version
vector
metadata
payload_ref
created_at
updated_at
deleted_at

The payload itself may live elsewhere. For a document assistant, the payload is the chunk text. For product search, the payload is a product record. For image search, the payload may be an asset reference.

Embedding version is critical. Vectors from different embedding models usually should not be mixed in one search space unless the system has explicitly designed for that. Re-embedding migrations often create parallel collections:

docs_v1 -> old embedding model
docs_v2 -> new embedding model

Traffic can shift gradually while quality and latency are evaluated.

7. Request Lifecycle

1. A client embeds the query or sends a query vector.
2. The query API validates dimension, collection, and tenant.
3. The planner evaluates metadata filters.
4. The ANN index returns candidate IDs and approximate scores.
5. The system applies final filters and removes deleted or unauthorized records.
6. Candidate vectors or payload metadata are fetched.
7. Results return with IDs, scores, and references.
8. Metrics record latency, candidate count, filter selectivity, and search path.

For ingest:

1. The client sends vectors and metadata.
2. The ingest API validates schema and writes durable intent.
3. The vector store persists records.
4. The index update path makes records searchable.
5. Background jobs compact and rebuild derived structures.

8. Scaling Problems

Vector databases scale along several axes: vector count, vector dimension, query rate, filter complexity, update rate, and tenant count.

Common scaling problems include:

• memory growth from large indexes
• slow rebuilds when embedding versions change
• poor recall when approximate search is tuned too aggressively
• high latency when filters select tiny subsets
• stale results after deletes or permission changes
• hot tenants dominating query capacity
• write amplification from index updates and compaction
• operational pain from backing up large vector collections

Filtering is especially tricky. If the system searches globally and filters afterward, it may return too few valid candidates. If it filters first, the ANN index may not work well on a tiny subset. Production systems often need multiple strategies.

9. Distributed Systems Concepts

Derived data: the ANN index is derived from durable vector records and can be rebuilt.

Eventual consistency: newly ingested vectors may not become searchable instantly.

Tombstones: deletes often need markers so queries stop returning records before compaction removes them physically.

Partitioning: collections may be partitioned by tenant, shard key, time, or hash.

Recall versus latency: approximate search trades perfect nearest-neighbor accuracy for speed.

Backpressure: ingest and rebuild jobs must not starve query serving.

10. Reliability & Failure Handling

The service should distinguish data durability from index availability. If an index shard fails, the system may route around it, degrade recall, or reject queries for affected collections. If an ingest worker fails after writing the durable log, replay should restore the missing index update.

Important signals include:

• query p50, p95, and p99 latency
• recall on sampled exact-search probes
• index memory and disk usage
• ingest lag and delete lag
• failed filter ratio
• shard imbalance
• rebuild duration
• embedding-version traffic split

A dangerous failure is silent data leakage through filters. Permission filters should be tested with adversarial cases, not treated as ordinary metadata.

11. Real-World Company Approaches

A company building vector search may use specialized vector databases, search engines with vector support, or custom indexes attached to existing storage. Some products favor managed services to reduce operational burden. Others build dedicated systems for tighter control over latency, memory, and filtering semantics.

Public engineering patterns suggest that serious vector search systems separate durable records from derived indexes, monitor recall, and treat embedding migrations as data migrations rather than simple config changes.

12. Tradeoffs & Alternatives

The right architecture depends on query volume, update rate, filter strictness, and whether retrieval quality is central to the product.

13. Evolution Path

1. Start with exact search over a small dataset.
2. Add a vector database or vector index.
3. Add metadata filters and collection boundaries.
4. Add background ingest and durable replay.
5. Add approximate indexes with recall monitoring.
6. Add shard management and hot-tenant isolation.
7. Add re-embedding migration workflows.
8. Add hybrid search, re-ranking, and product-specific quality evals.

The system evolves when search stops being a demo and becomes product infrastructure.

14. Key Engineering Lessons

• A vector database is not just an array store; it is a search-serving data system.
• Embedding versioning matters because vector spaces are model-specific.
• Metadata filters are correctness features, not decoration.
• ANN indexes need recall monitoring because faster is not automatically better.
• Deletes, permissions, and rebuilds are where production vector search becomes serious.

15. Related Topics

• Vector Databases
• Vector Search
• ANN Indexes
• HNSW Indexes
• Cosine Similarity
• Hybrid Search