Vector Databases Explained

Part 1 and 2 covered embeddings conceptually. This part covers the real, practical infrastructure for actually using them at scale — a vector database, and precisely what it does that a normal database genuinely can't.

The real, core problem a vector database solves

Given a new real question's embedding vector, find the K most
  similar vectors among potentially MILLIONS of stored real document
  embeddings — as fast as possible

A real, normal database (the kind covered in the Django series' own ORM coverage) is genuinely built to find exact matches or filter by real, structured conditions — WHERE customer_id = 42. It has no native, efficient way to answer "which of these million real vectors is numerically closest to this one," a fundamentally different, real kind of query.

Why brute-force comparison doesn't scale

# genuinely works, but only for a SMALL real number of documents
def find_similar(query_vector, all_documents):
    scored = [
        (cosine_similarity(query_vector, doc.vector), doc)
        for doc in all_documents
    ]
    scored.sort(reverse=True)
    return scored[:5]

This real, brute-force approach — comparing a query against every single stored real vector — is exactly correct and exactly what part 6's small demo actually does. It's also genuinely too slow for real scale: comparing against a hundred real documents takes milliseconds; comparing against ten million real documents, one at a time, does not.

What a real vector database actually adds: approximate nearest-neighbor search

A real, specialized indexing structure (commonly HNSW — Hierarchical
  Navigable Small World graphs) organizes stored vectors so a real
  search finds the approximately-closest matches WITHOUT comparing
  against every single one

This is the real, genuine technical core of what a vector database provides — not just "a database that stores vectors," but a specific, real indexing algorithm that makes similarity search fast at real scale, trading a tiny, real amount of accuracy (it's "approximate," not guaranteed-exact) for a massive, real speed improvement.

Real, common vector database options

Chroma: a real, open-source, lightweight option — genuinely easy to
  run locally for development, this series' own choice for part 6's
  hands-on build
Pinecone: a real, managed, hosted vector database — no real
  infrastructure to run yourself, priced per real usage
pgvector: a real, genuine extension adding vector search directly to
  PostgreSQL — useful when a real project already uses Postgres and
  wants to avoid a separate, additional database system entirely

Each represents a real, different point on a genuine trade-off between operational simplicity, cost, and scale — covered concretely in part 4's comparison, once this part's conceptual foundation is in place.

A real, minimal, concrete example with Chroma

import chromadb

client = chromadb.Client()
collection = client.create_collection("bright_leaf_faqs")

collection.add(
    documents=["Orders ship within 24 hours of roasting."],
    ids=["shipping-1"],
)

results = collection.query(
    query_texts=["how fast do you ship"],
    n_results=1,
)
print(results["documents"])
# → correctly retrieves the shipping doc, despite zero literal word
#   overlap with the query — exactly part 1 and 2's core point,
#   now running in real, actual code

Notice collection.add() and collection.query() handle the real embedding generation automatically in this example — Chroma can generate embeddings internally by default, though a real production setup often generates embeddings explicitly (using the same model consistently, per part 2's warning) and passes them in directly for more control.

What a vector database is genuinely NOT a replacement for

A vector database excels at: "find documents semantically similar
  to this query"
A vector database is NOT built for: real, structured filtering like
  "orders from the last 30 days where status = shipped" — a normal,
  real relational database still does that better

Many real, production systems use both together — a normal database for structured data and real business logic, a vector database specifically for semantic search — rather than treating one as a full replacement for the other.

Next: choosing a real vector database — a practical, concrete comparison of Chroma, Pinecone, and pgvector for this series' actual projects.