Why One Team Ditched Its Vector Database and Moved Embeddings Into Postgres

A development team abandoned a dedicated vector database after a year, despite it being faster on pure nearest-neighbour benchmarks, because real-world queries always combined vector search with metadata filters like user permissions and workspace scope. Dedicated vector stores handle such filtered searches poorly, either discarding their index via pre-filtering or returning incomplete results via post-filtering, forcing the team to over-fetch and make a second round-trip to Postgres anyway. The deeper issue was a dual-write problem: storing embeddings separately from source data meant any failure during the two-step write process could leave vectors stale or orphaned, silently breaking search results or leaking access to deleted content. The team concluded that an embedding is derived data — like a thumbnail from an image — and should live alongside the source record, not in a separate system with its own failure modes. Moving to a single Postgres column with an HNSW index eliminated the sync pipeline, the consistency risks, and the extra infrastructure bill.