Postgres Doesn’t Want a Separate Vector DB

What it does

pg_vectorize turns a Postgres database into a retrieval backend by generating embeddings from table columns, keeping them synchronized as data changes, and exposing both semantic and full-text search. It packages the whole pipeline—transformation, orchestration, and hybrid ranking—either as a native extension or as a standalone HTTP service that sits next to your database.

The interesting bit

The project’s real value is in the plumbing it hides. Instead of manually wiring up triggers and batch jobs to re-embed rows, it uses background workers to watch tables and update vectors automatically. It also offers a managed-database escape hatch: if you can’t install extensions on RDS or Cloud SQL, the HTTP server mode talks to Postgres using only pgvector, while self-hosters get pure SQL functions like vectorize.table() and vectorize.search().

Key highlights

• Hybrid search returns full-text rank, semantic similarity, and a fused rrf_score in a single query.
• Two deployment modes: sidecar HTTP API for managed Postgres, or an in-database extension for self-hosted setups.
• Background orchestration via pgmq keeps embeddings fresh without manual triggers or external schedulers.
• Hooks into popular LLMs and sentence-transformers models for the embedding generation step.

Verdict

This is for teams already committed to Postgres who need vector or RAG capabilities but would rather not babysit a separate vector store. If you want a fully managed, standalone vector database with its own scaling story, this adds complexity you don’t need.