yash@jain:~$

../ yash@jain:~$ cat /archive/you-might-not-need-a-vector-db.md

noteServers & self-hosting

I moved servers and the vector database didn't survive the list

Vector search is the fashionable way to make your notes searchable. I ran one anyway. Then a move between servers made the decision for me — and nothing broke.

Every guide to making your own notes searchable says the same thing. Embeddings and a vector database. A vector database stores the meaning of text so an AI can find similar passages — think of it as search by vibe instead of search by word. It’s the answer in every thread, every tutorial, every stack screenshot.

I ran one. Not because I had a plan for it, but because it was the thing you were supposed to have. When I moved to a new server in June 2026, everything on the old box got sorted into two columns: worth the move, or not. Qdrant — the vector database, a container idling at around 200MB of memory — landed on the retire list. The honest answer is it was running and I couldn’t have told you what for.

Then the part I didn’t expect. Nothing broke. The next day, the next week, no moment where I thought, ah, this is where the vector search would have helped.

A move is the only honest audit you’ll ever run. Adding things is frictionless. Every tool takes one evening to install, so your setup only ever grows. Deleting is where you learn what was real — because for a tool to survive a migration, you have to decide it’s worth moving. Every retire list is a list of things you were paying for in memory, updates, and attention you weren’t getting back. When one goes and the house stays standing, that’s the answer to a question you’d been avoiding.

The memory hub was the interesting one, and it never had embeddings at all. I built a shared notebook so my AI tools would stop forgetting everything between sessions. The obvious design was embeddings and a vector database. I used neither, and I still don’t. My search is plain keyword matching. It’s boring, it works offline, and — the part I actually care about — it can’t invent a match that isn’t in the files. When an agent recalls something, that thing definitely exists. No second system to keep in sync, no API bill for indexing my own notes, and when a result looks wrong I open the file and see why.

That’s the difference between fashion and a decision. The vector database was fashion — I had it because the default advice said to. The keyword search was a decision, made on purpose, for reasons I could defend. One survived the move. The other one I didn’t notice leaving.

Every fashionable tool is a running service, and a service is a bill you pay in three currencies. Memory on a box you rent by the month. Time to update and back up. And attention — the part nobody puts on the invoice. A service whose purpose you can’t remember is the worst version of all three.

I’m not saying vector search is wrong. If you’re searching a library by meaning, or handling queries where you don’t know the words, you probably need it. So that’s the test: name the question you can’t answer without it. I couldn’t name one. The questions I actually ask my own notes — what did we decide about this, when did that break, which box is that on — keyword search answers every time.

So the rule I’d hand anyone building their own stack: run the cheap thing until it demonstrably fails. Not until you imagine a case where it might. Until you hit a real question, on a real day, that the cheap thing can’t answer. Most of the expensive machinery people install is insurance against a failure that never arrives, and the premium comes due every month.

The best signal that you didn’t need a tool is that you never noticed it was gone.

Related reading

← cd /archive