The database is where it becomes a system

A retrieval deployment needs to store documents, chunks, embeddings, users, permissions and logs. A relational database with a vector extension does all of it, in one place, with one backup, one restore, one access-control model and transactions across the lot.

A dedicated vector database is the right answer at a scale most organisational deployments never reach, and it is the wrong answer for a firm with a hundred thousand chunks. The cost of the second store is not licence money, it is the two systems that must agree about what has been deleted.

Approximate nearest-neighbour indexes trade recall for speed: they return a good set of neighbours quickly, not necessarily the best set. That trade is invisible until you evaluate, which is why lesson 03 came first. Build your baseline with exact search on a small collection, then measure again after adding the index and see what you gave up.

Then check the arithmetic on your own numbers. At a few tens of thousands of chunks, exact search is often fast enough, and an index you did not need is a source of surprising answers.

Your customer will eventually have to remove a client’s material: a matter closes, a contract ends, a person exercises a right. That means deleting the file, the extracted text, every chunk, every embedding, the cached answers, and whatever the logs kept. If that is several systems, deletion is a project each time.

Write the delete before you need it and run it on test data. A retention promise you cannot execute is worse than one you never made, and this is the point in the build where it is cheap to get right.