Postgres vector search heats up as memory gets expensive
Tiger Data released pg_vectorsearch, an index claiming to beat pgvector's IVFFlat and HNSW. The first practical question was whether it supports filtering, and the answer was post-filtering only. That makes per-tenant and permission scoping hard, a real blocker for B2B apps. One commenter already runs VectorChord and said a fast disk cut their Postgres cost in half. They welcomed competition in low-RAM indexes and referred to "RAMageddon."
A neighboring thread compared InnoDB and Iceberg internals, with a commenter suggesting DuckDB would beat Spark at that scale. The common thread is shrinking the infrastructure bill by using what you already run. Postgres for vectors, DuckDB for analytics, and fast disks in place of more RAM.
The nuance is that benchmarks don't settle it. Filtering, multi-tenancy and cost under real load decide whether these indexes are usable.
So what?
If you're building RAG or search features, you probably don't need a separate vector database. Postgres is catching up fast. Test any index with your real tenant filters, not just recall benchmarks, and watch RAM cost as the main variable.