Part 1 ·
Vectors, Plainly, part 1: what a vector database actually does
A vector database answers “what is closest in meaning to this?” instead of “which rows match?”. Here is the machinery: embeddings, distance, and why you never design the fields.
Series · 6 parts
Vectors, Plainly
What a vector database does, in six parts: the idea, the index, tenancy, retrieval quality, RAG, and production.
Part 2 ·
Vectors, Plainly, part 2: inside the index, from HNSW to hybrid search
How HNSW graphs, IVF cells and product quantization make nearest-neighbour search fast, and how filters, keyword fusion and reranking change what a query returns.
Part 3 ·
Vectors, Plainly, part 3: multi-tenancy, and how to organise data in a vector database
A vector index has no row-level security by default, and a missing filter leaks data without an error. The isolation levels, what each engine offers, and how to lay out collections, namespaces and metadata.
Part 4 ·
Vectors, Plainly, part 4: getting retrieval quality right
Retrieval quality is decided by the embedding model, the dimensions and the chunking, and it is only known once you measure recall. How to choose, how to test, and where vector search earns its place.
Part 5 ·
Vectors, Plainly, part 5: RAG end to end, GraphRAG, and graphs beside vectors
Retrieval-augmented generation is an architecture, and the vector database is one box in it. The whole loop, the RAG variants worth knowing, reranking, and when a knowledge graph beats similarity.
Part 6 ·
Vectors, Plainly, part 6: running a vector database in production
The parts tutorials skip: sharding and write freshness, memory and disk-based indexes, where a GPU actually pays off, and the security and compliance questions a vector store raises.
