I have spent a lot of years thinking about MySQL: indexes, explain plans, the difference between “the query is slow” and “we are asking the wrong question”. Vector databases showed up in my reading with the confidence of a replacement. I do not think they are a replacement. I think they are a different index, for a different kind of question.
This is a learning note. I am not deploying a RAG platform in this post.
What problem they actually have
A B-tree is excellent at this key, or this range. It is a bad tool for this meaning, approximately.
If I have a million support notes and I want “things that are like this error message”, LIKE '%misdirected%' is a joke. Full-text search is better and still lexical. Embeddings try to turn text into coordinates so that “nearby” means “semantically related”, with all the caveats that sentence deserves.
A vector database stores those coordinates and answers nearest-neighbour queries.
What I am not outsourcing
The rest of the system is still a system:
- where the source of truth lives (still a relational database, in every design I would trust)
- when you re-embed after an update
- who is allowed to see a neighbour (retrieval is not authorization)
- what you do when the neighbour is confidently wrong
The MySQL instinct that still helps
- Indexes are tradeoffs. You pay write cost for read shape. Embedding pipelines are a write cost.
- Explain is a habit. I want to know why a chunk was retrieved, not only that it was.
- Latency budgets exist. A 2ms primary key lookup and a 40ms ANN query are different animals. Design the page accordingly.
I will keep notes as I actually build something. Until then, the honest status is: I can explain the problem they solve, I have not yet earned opinions about vendors.