You’ve been told you need a vector database to build AI features. That’s a lie. And it’s costing you time, money, and sanity.
Every week, another startup pitches me their ‘AI-native’ stack. Vector DB here, embedding pipeline there. Meanwhile, their entire dataset fits in a spreadsheet. They’re solving problems they don’t have yet.
Here’s the truth: for up to one million documents, brute-force search with plain NumPy is not just viable—it’s optimal. The math is embarrassingly simple: modern CPUs can compute 10,000+ cosine similarities per millisecond. A million vectors? That’s a hundred milliseconds. End of story.
I first saw this logic in a blog post titled ‘Just brute force your embeddings’—a reality check that should be required reading for every AI engineer. The author ran the numbers, and they’re devastating to the vector DB hype machine.
Think about it. How many apps truly have a million distinct documents? Even the most ambitious SaaS product takes years to get there. By the time you hit that wall, you’ll have the revenue, the team, and the clarity to choose the right specialized tool. Until then, you’re optimizing for a scale that doesn’t exist.
If you start with a vector database, you’re paying for complexity you haven’t earned. You’re debugging index rebuilds, managing shards, and arguing about latency when you could be shipping features. The sunk cost of those decisions kills momentum.
But here’s the twist: the moment you actually need a vector DB, you’ll know. Your NumPy script will take 400 milliseconds. Then 800. Then it starts timing out. That’s the signal. Not before. Not ‘in case we grow.’ When it hurts, you upgrade.
I’ve watched teams burn months on infrastructure that never paid off. One team spent six weeks migrating from a simple NumPy solution to a distributed vector DB, only to discover their data was 70k vectors. They never needed the move. They just believed the hype.
Stop building for unicorn scale when you’re a seed-stage startup. The smartest AI engineers I know start with a CSV file, a few lines of Python, and a brute-force loop. They add complexity only when the pain is undeniable.
So next time an architect suggests a vector database, ask: ‘How many documents do we have today?’ If the answer is under one million, say no. Save your money. Brute force it. And when you finally hit the limit, you’ll be ready.
FAQ
Q: Isn't brute-force search too slow for production use?
A: No. On modern hardware, computing cosine similarity for 1 million vectors takes under 100ms. That's fast enough for most real-time applications. Only when you cross 10 million vectors does latency become an issue.
Q: When should I actually consider a vector database?
A: When your dataset exceeds 10 million vectors, or when you need advanced features like hybrid search, multi-tenancy, or real-time indexing. The key is to wait until you hit a measurable performance wall—not preemptively.
Q: But everyone says vector databases are essential for AI apps. Are they wrong?
A: They're not wrong for large-scale systems. But the majority of AI apps never reach that scale. The hype is driven by vendors and early adopters, not by the needs of most developers. Start with brute force, validate your product, and scale only when data proves it necessary.