Day 12: Vector Databases — Storing and Searching Enterprise Knowledge

2026-10-12 · 9 min read

Watch the video lesson, or subscribe on YouTube for a new lesson every day.

Yesterday you turned text into embeddings. Now you have a new problem: where do millions of those vectors live, and how do you find the closest ones to a question fast?

In plain terms: A normal database is a filing cabinet with labelled folders. You ask for the folder called "open" and it hands it over. A vector database is a librarian who understands what you mean and brings the books that are closest to your idea, even if no label matches.

A relational database answers exact-match questions. A vector database answers the question closest to this meaning by ranking stored embeddings by distance, which standard databases are not built to index.

1. The vector store

Standard relational databases such as PostgreSQL or MySQL are built to search for exact matches: WHERE status = 'open'. They have no efficient way to answer "which stored vectors are closest to this one?" That job needs geometry. A vector database such as Milvus, Qdrant or Pinecone is engineered to store and index millions of embeddings and to answer that question efficiently.

2. Approximate nearest neighbour (ANN)

You could compare your question against every stored vector, but at a million documents that is far too slow. Vector databases build an index instead. HNSW (Hierarchical Navigable Small World) is a popular one: it links vectors into a layered graph, so a search starts at a coarse layer and hops closer and closer to the answer. The trade is a little accuracy for a lot of speed, which is why it is called approximate.

Comparing a query against every vector is too slow at scale. Approximate nearest neighbour indexes such as HNSW hop through a layered graph to reach close matches in milliseconds, trading a little accuracy for a lot of speed. The comparison counts are illustrative.

3. pgvector: no new system required

If your team already runs PostgreSQL and does not want another database to operate, the pgvector extension adds a vector column type and similarity search to it. Your embeddings sit right next to your normal relational data, so one query can filter by customer and rank by meaning.

You can store embeddings in a dedicated vector database such as Milvus, Qdrant or Pinecone, in PostgreSQL with the pgvector extension next to your regular data, or in a local library for small experiments.

Here is a complete pgvector example. The three-number vectors are only there to keep it short; real embeddings have hundreds of dimensions, and the vector(3) size would match your model's output.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE docs (
  id        serial PRIMARY KEY,
  body      text,
  embedding vector(3)          -- use your model's size, e.g. vector(1536)
);

INSERT INTO docs (body, embedding) VALUES
  ('High latency on the web tier',   '[0.82, -0.11, 0.47]'),
  ('Packets dropped at the switch',  '[0.79, -0.08, 0.51]'),
  ('Quarterly revenue forecast',     '[-0.12, 0.55, 0.20]');

-- An index makes this fast at scale (HNSW with cosine distance):
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);

-- The 2 paragraphs closest in meaning to the question's vector.
-- <=> is cosine distance: smaller means closer.
SELECT body
FROM docs
ORDER BY embedding <=> '[0.80, -0.10, 0.49]'
LIMIT 2;

Put it together and a query looks like this: embed the question, ask the vector database for the nearest vectors, and get the matching paragraphs back.

A question is turned into a vector by the embedding model, the vector database finds the nearest stored vectors, and the matching paragraphs come back ranked by closeness.

Coming Up Next

Day 13: Retrieval-Augmented Generation (RAG): chatting with proprietary documents.

#VectorDatabase #DataScience #DataArchitecture #BackendEngineering #AI