PostgreSQL for Everything
raphaelbauer.com
August 19, 2026
8 min read
66/100
Summary
PostgreSQL can consolidate functions commonly assigned to separate search, document, queueing, analytics, caching, vector, graph, and storage systems, according to software executive Raphael Bauer. Bauer has used PostgreSQL since about 2003, initially for the ColumbaDB research project, where a full-text-search plugin avoided operating a separate Lucene or Solr system. More recently, he used the TimescaleDB extension to store high-volume web-analytics time-series data for Privatracker. PostgreSQL, first released in 1996, has added capabilities including JSON document storage, partitioning, common table expressions, full-text search, recursive queries, and extensions. Its GIN indexes support JSON querying, while `SELECT FOR UPDATE` and `SKIP LOCKED` can let database tables serve as work queues with multiple consumers. Timescale extends PostgreSQL for time-series workloads, and Bauer says pgvector and pgai support vector indexing, similarity retrieval, and LLM-related workflows. He also cites unlogged tables as a possible cache alternative, LTREE for hierarchical data, and JSON-returning queries for reducing middleware needs. Bauer recommends beginning with PostgreSQL when new requirements arise and adopting specialized systems such as Kafka, RabbitMQ, SQS, ClickHouse, Redis, MongoDB, Solr, or Elasticsearch only when PostgreSQL no longer meets performance or functional needs.
Key Takeaways
- PostgreSQL combines relational data management with full-text search, JSON storage and querying, partitioning, recursive queries, and an extension ecosystem.
- `SELECT FOR UPDATE` and `SKIP LOCKED` can support PostgreSQL-backed work queues with persistent or read-once consumption patterns.
- TimescaleDB extends PostgreSQL for high-volume time-series data, while pgvector and pgai are presented as tools for vector retrieval and LLM workflows.
- Bauer argues that PostgreSQL can reduce operational complexity by replacing some specialized infrastructure for search, document storage, queues, caching, analytics, and hierarchical data.
What the discussion said
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.
Where opinion split
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.
Coverage & discussions
Hacker News · raphaelbauer.com
Community discussions
Community Sentiment
Positives
- Keeping embeddings in PostgreSQL can spare an early RAG product a separate vector service, reducing operational surface area while requirements are still uncertain.
- Several commenters see pgvector as a pragmatic first stop for AI retrieval: launch simply, measure real bottlenecks, then introduce specialized infrastructure only when justified.
Concerns
- 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.
- 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.
