pgvector for RAG: Capabilities and Limits

pgvector is a PostgreSQL extension that stores vectors beside relational rows so RAG teams can run similarity search inside the database they already operate. The pgvector project README (github.com/pgvector/pgvector, as of September 2026) documents the extension for vector similarity search in Postgres, including distance operators and index types maintained in that repository. The appeal is operational consolidation: one backup regime, one access-control story, one query language. The limit is that Postgres becomes both system of truth and ANN service, so recall, memory and vacuum behaviour become shared fate. Category background lives at vector databases; scored fit lives at which vector database should you use for RAG.

What is pgvector, and what makes it useful for RAG?

pgvector is a PostgreSQL extension that adds vector columns, distance operators and approximate indexes so nearest-neighbour queries can run in SQL beside joins and filters on ordinary tables. The GitHub README is the canonical capability source for operators, index build options and version notes. Managed Postgres vendors often package the extension; the extension itself remains the open-source component you verify by version.

For RAG, usefulness is the single-database path. Permissions, tenant keys and document foreign keys can live next to embeddings without a second cluster. Usefulness declines when ANN scale and specialised hybrid features outgrow what your Postgres instance can absorb without harming transactional latency.

pgvector does not invent embeddings or chunking. It stores the vectors you produce and returns neighbours under the operators and indexes you configure. Wrong chunks remain wrong neighbours even when SQL is elegant.

How does pgvector change RAG architecture?

pgvector changes RAG architecture by collapsing the retrieval store into Postgres. Application code can join chunk rows to product or ticket rows in one transaction boundary, and backups already cover vectors if they live in the same database. That consolidation is why many early production RAG systems start here when Postgres is already sacred infrastructure.

The architectural cost is shared resources. Heavy index builds, large vector scans and transactional spikes compete for the same CPU, memory and I/O. Teams that need isolation often split read replicas or eventually move ANN to a dedicated store while keeping Postgres as source of truth.

Filtering is often ordinary SQL WHERE clauses plus vector ORDER BY distance. That is powerful and familiar. It is also easy to write a query that looks correct and still returns the wrong neighbour set when indexes are missing or when predicates are too selective. Depth on filter design lives at metadata filtering.

What are pgvector capabilities and limits side by side?

pgvector capabilities arrive with Postgres-shared limits. The pairs below keep both sides visible using the project’s README language as of September 2026, without inventing latency or cloud price figures that the extension repository does not publish as a hosted menu.

One-database convenience is the headline; the limits are shared-fate performance, specialised ANN features that dedicated stores advertise, and the need to tune indexes for your dimension width. Those limits are why this profile refuses to treat pgvector as free scale.

Approximate index parameters trade recall for speed inside Postgres. Measure on your labelled queries before and after parameter changes. Do not copy a blog’s parameter set as if it were a universal optimum.

When is pgvector the right RAG store?

pgvector is the right RAG store when Postgres is already the system of truth, when object counts fit comfortably on your instance class, and when SQL joins between business rows and chunks are more valuable than a specialised vector product. It fits teams that want one operations surface more than they want a separate ANN cluster.

pgvector is the wrong default when you need a dedicated distributed vector database’s feature set, when vector traffic would starve transactional workloads, or when hybrid lexical-plus-dense retrieval must live in a specialised engine you do not want to rebuild in SQL. It is also a weak fit when your team cannot tune Postgres indexes and vacuum behaviour.

Weaviate remains the open-source baseline when you want a purpose-built vector database with modules. FAISS remains the library path when you want ANN inside an application process without Postgres. Neither sentence crowns a winner; both route to profiles and the survey.

What should you verify before production use?

Before production use, verify the pgvector version against the README for your Postgres major version, confirm index build options for your dimension width, and keep a labelled query set that scores retrieval separately from generation. Confirm delete and update paths so retracted documents leave vector columns.

Also verify that host packaging matches the extension version you tested, and verify monitoring covers both transactional and ANN query latency separately. Capacity planning should include embedding storage growth. Re-run evaluation after every embedding model swap.

If pgvector clears those checks, keep vectors in Postgres and treat retrieval as a SQL concern. If it fails isolation or scale checks, open Weaviate, Qdrant or another profile instead of overloading the primary database.

Who owns upgrades, restores and recall monitoring?

Upgrades, restores and recall monitoring decide whether a store survives production, because a good neighbour on a laptop does not prove deletes propagate, filters still hold under load, or an embedding model swap is followed by a full re-index. Those are ownership questions as much as product questions, and they belong in the runbook before traffic arrives.

Name the person who upgrades the version, the person who restores from backup, and the dashboard that shows retrieval recall separately from generation scores. If those names are blank, prefer a managed path or delay production claims until staffing exists. Capacity planning should use your real dimension width, object count and filter cardinality rather than a tutorial corpus.

How should you evaluate retrieval after you pick the store?

You should evaluate retrieval after you pick the store by keeping a labelled query set, scoring neighbours before generation, and re-running after every schema, filter or embedding change. Generation fluency will hide wrong chunks if you only read final answers. Stage separation is how you know whether to change the store, the chunker or the prompt.

Include filtered queries in the set if production uses filters. Unfiltered recall can look healthy while tenant or source filters destroy candidates. Include exact-token queries if your users ask for error codes and SKUs; dense-only stores will fail those unless hybrid or lexical paths exist. Document the as-of date of every vendor claim you relied on, and treat unpublished numbers as not published.

How does this store sit beside Weaviate and neighbouring profiles?

This store sits beside Weaviate and neighbouring profiles as one shape in an ordered field, not as a universal winner. Weaviate remains the batteries-included open-source baseline with modules when that control model matters. Neighbouring managed and self-host profiles cover serverless, filtering-first and in-database extension paths without requiring this profile to invent a latency leaderboard.

Use the category hub at vector databases for definitions and the survey at which vector database should you use for RAG for scored fit across stores. Keep internal links in prose, keep sources named rather than linked externally, and keep every volatile claim dated in the same sentence that carries it.

What else should you confirm before you scale beside Weaviate and neighbouring profiles?

This store sits beside Weaviate and neighbouring profiles as one shape in an ordered field, not as a universal winner. Weaviate remains the batteries-included open-source baseline with modules when that control model matters. Neighbouring managed and self-host profiles cover serverless, filtering-first and in-database extension paths without requiring this profile to invent a latency leaderboard.

Use the category hub at vector databases for definitions and the survey at which vector database should you use for RAG for scored fit across stores. Keep internal links in prose, keep sources named rather than linked externally, and keep every volatile claim dated in the same sentence that carries it.

Who owns upgrades, restores and recall monitoring?

Upgrades, restores and recall monitoring decide whether a store survives production, because a good neighbour on a laptop does not prove deletes propagate, filters still hold under load, or an embedding model swap is followed by a full re-index. Those are ownership questions as much as product questions, and they belong in the runbook before traffic arrives.

Name the person who upgrades the version, the person who restores from backup, and the dashboard that shows retrieval recall separately from generation scores. If those names are blank, prefer a managed path or delay production claims until staffing exists. Capacity planning should use your real dimension width, object count and filter cardinality rather than a tutorial corpus.

How should you evaluate retrieval after you pick the store?

You should evaluate retrieval after you pick the store by keeping a labelled query set, scoring neighbours before generation, and re-running after every schema, filter or embedding change. Generation fluency will hide wrong chunks if you only read final answers. Stage separation is how you know whether to change the store, the chunker or the prompt.

Include filtered queries in the set if production uses filters. Unfiltered recall can look healthy while tenant or source filters destroy candidates. Include exact-token queries if your users ask for error codes and SKUs; dense-only stores will fail those unless hybrid or lexical paths exist. Document the as-of date of every vendor claim you relied on, and treat unpublished numbers as not published.

pgvector is a PostgreSQL extension that puts similarity search beside relational data, with operators and indexes documented in the September 2026 GitHub README. It fits RAG teams that value one-database operations and SQL filters. It still shares fate with transactional workloads and does not publish a universal public latency menu. Measure recall on your queries, keep Weaviate first among dedicated stores in ordered lists, and open the survey when more than one shape still fits.