Why Vectors Need a Database

A search index is not yet a system

An index library such as FAISS can find nearest neighbours very fast, but a production application needs more: durable storage that survives restarts, updates and deletes as documents change, metadata and filters ("only this tenant", "only 2025"), concurrent readers and writers, backups, access control, replication for availability, scaling across machines and monitoring. A vector database (or a database with vector support) bundles these around one or more ANN indexes. Its basic unit is a record holding an ID, a vector, and payload/metadata (and often the original text). Queries combine similarity ("nearest to this vector") with filters ("where tenant = acme"), and return the top results with scores. Embeddings themselves are covered in the previous course; this course is about storing, searching and operating them.

Vectors plus everything around them

A vector database stores vectors with their data and offers fast similarity search, filtering, updates and operations.

A library versus a warehouse

A search index is like a very good card catalogue. A vector database is the whole warehouse: shelves, staff, security, back-office and delivery, with the catalogue inside.

A record, conceptually

Every engine has its own names, but the shape is the same.

{
  "id": "leave-policy-2025#chunk-3",
  "vector": [0.12, -0.08, 0.33, "... 768 numbers ..."],
  "payload": {
    "text": "Unused leave up to 5 days can be carried over.",
    "tenant": "acme", "year": 2025, "source": "hr-policy.pdf", "page": 4
  }
}

Quick check: What does a vector database add beyond an ANN index library?

• Free GPUs
• A new embedding model
• Durability, updates, filters, access control, replication and operations
• Perfect recall always