November 3, 2025
Vectors vs vibes
The Case Against PGVector
Devs say the demo is easy, real life hurts — others brag it powers billions
TLDR: A teardown of pgvector warns that what works in demos can stumble at scale, but users like Discourse say they run it widely and a key pain was fixed in version 0.8.0. The debate splits between “keep it simple in Postgres” and “separate a real vector engine,” with scale and risk at stake.
A spicy blog calls out pgvector—the Postgres add-on that lets apps “find similar things” with math—for being great in demos but painful in real life. The comments section? Absolute cage match. One camp says keeping everything in one database is tidy in theory but messy in practice. User cpursley went full meme mode about “the hot new VC database of the month” and the “balls of mud” you end up writing to glue it all together. Another crowd fires back: xfalcox claims they run it at Discourse across thousands of databases and billions of page views, adding that a key pain point was fixed in v0.8.0 with Iterative Scans.
Key Points
- •The article argues that pgvector demos and tutorials often omit crucial production considerations.
- •It claims many guides are based on small datasets and optimistic benchmarks, lacking operational depth.
- •pgvector offers two index types—IVFFlat and HNSW—with non-trivial trade-offs for production use.
- •IVFFlat’s advantages include lower memory during build, reasonable query performance, and faster index creation than HNSW.
- •IVFFlat requires careful tuning of the number of lists, which strongly affects recall and performance; common heuristics are only starting points.