Postgres + pgvector: The RAG Solution You Already Have

If you're building a RAG-enabled application and feeling overwhelmed by the ever-growing list of specialized vector databases, here's some good news..

If you're building a RAG-enabled application and feeling overwhelmed by the ever-growing list of specialized vector databases, here's some good news: you might already have everything you need. PostgreSQL, the battle-tested open-source database that millions of developers already know and love, has quietly become a genuinely great foundation for RAG systems thanks to the pgvector extension. With pgvector installed, Postgres can store and search vector embeddings right alongside your regular data — no extra infrastructure, no new query language to learn, no separate service to keep alive.

What makes this so compelling is its simplicity. Instead of running a dedicated vector database and a relational database and wiring them together, you get everything in one place. Your embeddings live next to the data they describe, your queries can join vector search results with relational filters in a single statement, and you only have one database to back up, monitor, and scale. One area where pgvector differs from dedicated vector databases, though, is hybrid search: combining semantic vector similarity with traditional keyword search. Honestly, don't let that scare you off. It's simply a SQL query that blends a vector similarity score with a full-text search rank, and once you've written it once, it's trivially reusable across your entire application. For most RAG workloads — chatbots, document search, semantic retrieval — pgvector's performance is more than sufficient, and the ecosystem around Postgres is (obviously) extremely good.

Yes, hyper-specialized vector databases shine at extreme scale or when you need cutting-edge features like multi-modal search or advanced HNSW tuning out of the box, but for the vast majority of teams building RAG applications today, reaching for a dedicated vector DB before trying pgvector is quite possibly not the right choice. Start with Postgres, add pgvector, and spend your energy on what actually matters: the quality of your embeddings and the intelligence of your retrieval logic. You can always add specialized tooling later if you genuinely outgrow it. In a lot cases, I think, you won't outgrow it.

When I started Voxum (https://voxum.ca) I immediately jumped to Weaviate for my vector store. Yes, it worked, and yes, it was simple enough to get it up and running, but after six months or so I realized that it was just another moving part that needed to be maintained, and it added a fair bit of code to the overall application. Using pgvector made things much simpler for my use case, and the switch to using it was relatively simple.

Also check out my RAG Python course: Building a RAG Application in Python

Categories: : RAG