PostgreSQL for Everything

Based on 15 sampled comments from this thread. Analyzed 2026-08-19.

The thread was overwhelmingly about general database architecture rather than AI, so the AI-specific discussion narrowed to whether PostgreSQL can credibly serve as the vector layer for retrieval-augmented generation. Commenters did not deny that pgvector is useful: for an early product, keeping embeddings beside application data can eliminate another service, simplify deployment, and make PostgreSQL a sensible default until real load proves otherwise. One reader explicitly framed it as a starting point that can be replaced only when a product has genuinely outgrown it. The skepticism was much sharper around production-scale retrieval. Several readers argued that vector extensions operate too independently from PostgreSQL’s ordinary planning machinery, making combined vector and relational queries harder to optimize and reason about. They also warned that the standard approximate nearest-neighbor approaches in pgvector become latency liabilities at very large collections, especially because RAG systems commonly create embeddings for many document chunks or image patches rather than one vector per item. The practical consensus was not that PostgreSQL is useless for AI search, but that it is attractive for modest workloads and risky to present as a universal substitute for a purpose-built vector system. Most other arguments about queues, OLAP, search, and SQL databases were not AI-related.

The central dispute is whether pgvector makes PostgreSQL an adequate vector database for AI retrieval. Supporters see one database for embeddings and product data as the pragmatic low-operations choice until scale demands otherwise; critics say opaque planning and deteriorating latency around hundred-million-vector collections make that shortcut fragile for serious RAG deployments.

• Praise: Keeping embeddings in PostgreSQL can spare an early RAG product a separate vector service, reducing operational surface area while requirements are still uncertain.
• Praise: Several commenters see pgvector as a pragmatic first stop for AI retrieval: launch simply, measure real bottlenecks, then introduce specialized infrastructure only when justified.
• Concern: pgvector’s vector indexes are treated as a black box by PostgreSQL’s planner, weakening optimization for retrieval workloads that mix similarity search with relational filters.
• Concern: Approximate vector search can hit painful latency at hundred-million-scale collections, a threshold RAG systems reach sooner when every chunk or visual patch gets embedded.