Vector Databases Are a Distraction. Here’s Where AI Builders Should Actually Look

The “should I use Postgres or a vector database?” argument has been raging for years now. Razin over at turbopuffer just threw another log on the fire with a post bluntly titled “RIP, vector database.” His argument, stripped of the hyperbole, is that Postgres plus pgvector is good enough for the vast majority of use cases, and running a separate specialized system adds operational overhead without proportional benefit. It’s a compelling read, and he’s not wrong for most teams.

But here’s what everyone arguing about recall@10 and HNSW parameters is missing: the database is the least interesting part of the modern AI stack.

Builders and indie hackers are spending an inordinate amount of time debating infrastructure when the real leverage is elsewhere. We (PainSignal) track 25,807 verified pain points across 89 industries, and you know what? Not a single one of them says “my vector database is too slow” or “I wish I had a better indexing algorithm.”

The problems that matter are grinding, unsexy, operational nightmares. Healthcare workers drowning in documentation. Teachers spending weekends on paperwork. Manufacturing supervisors chasing down compliance checklists. Finance teams copying data between systems by hand. These are the places where AI can create a step-change in someone’s daily life, and they’re exactly the places most builders ignore because they’re too busy arguing about database benchmarks.

Let’s get concrete. Our dataset shows 1,069 tracked problems in healthcare alone, with an average severity score of 5 out of 5. That’s not “nice to have” territory. That’s “this is actively burning our staff out” territory. We have app ideas like DripSafe Verification, which prevents IV medication mix-ups—a problem that kills people. VitalLink Alert monitors at-risk patients in real time. Nobody cares what database those apps use. They care that a nurse doesn’t accidentally administer the wrong drug at 3am.

Education paints a similar picture: 2,207 problems tracked and 950 app ideas generated. The pain is overwhelming, and the solutions don’t require anything fancier than a solid CRUD app with a document parser. A teacher tracking 150 students’ progress doesn’t need a billion-scale similarity search. They need an interface that doesn’t make them cry.

This isn’t to say Razin is entirely wrong. For most companies, he’s right—Postgres with pgvector is sufficient, and adding a specialized vector database is indeed extra operational overhead. Our own data reinforces a preference for pragmatic, integrated solutions over specialized infrastructure. When we look at how people actually solve operational problems, they’re reaching for tools that plug into existing systems, not standalone new databases. The “database as an afterthought” pattern is real.

But I’d push back on the notion that the entire vector database category has been a colossal waste of time. That’s taking a kernel of truth and driving it off a cliff. Specialized tools still matter when the stakes are high and the niche is intensely specific. The healthcare apps I mentioned are specialized, and they save lives. By analogy, a dedicated vector database serving a high-scale, high-velocity use case like real-time recommendation for a massive e-commerce platform—that’s not a waste. The problem isn’t the category; it’s the default assumption that every startup needs one.

The real lesson here isn’t “vector databases are dead.” It’s that infrastructure choices are a tax, not a product. The builders who win are the ones who minimize that tax and spend their energy on the actual problem space.

So here’s my challenge to the vibe coders and indie hackers out there: stop reading benchmarks. Stop scrolling vector database comparison tables. Go find a problem worth solving. We’ve already done a lot of that work for you—11,682 app ideas sitting in the PainSignal database, waiting for someone to build them. Pick one in healthcare, education, or manufacturing. Build it with whatever boring tech stack you want. Postgres, SQLite, a JSON file on a Raspberry Pi. Doesn’t matter. What matters is that you’re solving something that keeps a real person up at night.

The vector database debate is fun. It’s technical. It makes you feel smart. But it’s also a comfortable distraction from the harder, messier work of building something people actually need. The data doesn’t lie: the biggest, most severe, most urgent problems are nowhere near the database layer. They’re in the tired eyes of a nurse at the end of a double shift, and the stack of ungraded essays on a teacher’s desk.

Build for them.