Hien Hoang

Every team has the same pile: runbooks, decision records, postmortems, the page that explains what error E1042 means. Claude can use all of it, if it can search it. The usual answer is a vector database server, an embedding API and some glue.

This post builds the small version instead: a knowledge base in one folder, running on a laptop with no server and no API key, plugged into Claude Code as an MCP server. It does hybrid search, lets Claude save notes, ingests Markdown, PDFs and images, and keeps every version so a bad write can be undone. The code is on GitHub as lancedb-kb-mcp, with setup steps in the README.

The last post said that a vector database's real job is finding the nearest vectors quickly, and that most of them do it with an index called HNSW. pgvector, Qdrant, Chroma, Weaviate and Milvus all offer it.

This post opens that box: how the index is built, how a query walks it, what the three settings you will see in every product actually change, and why the answer is approximate.

Retries are easy to add. With SQS and Lambda you do not even add them: they are on from the first deploy. Safe retries are the hard part, and they are your job, not the platform's.

This post walks through where the second run of a message comes from, how to keep one bad message from replaying a whole batch, how to make the second run harmless, and how to keep the messages that never succeed in a state you can actually replay.

Most RAG tutorials start by setting up a vector database. For a lot of projects that is the first piece of infrastructure they did not need yet. For others it is the right call, and knowing which group you are in saves a migration later.

This post covers what a vector database actually does, how far plain exact search gets you, what Postgres can do with pgvector, and the point where a dedicated store earns its place.

A model API is simple: text goes in, text comes out. Every real application then rebuilds the same plumbing around that one call. LangChain is that plumbing, packaged once.

It helps to know which problem each part solves, because that also tells you when you do not need it. Here are the six problems, in the order most projects hit them.