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.
I set out to do one useful open source contribution a day, with a coding agent doing the legwork and me approving every comment and pull request before it went out. The plan was the classic one: find a small, fresh bug in a project I use, fix it, send the PR.
By the end of the first afternoon I had a problem. Almost every small, fresh bug I found already had a fix waiting.