PostgreSQL and pgvector: When Should AI Applications Use a Separate Vector Database?

An AI application can keep business records, embeddings and searchable documents in PostgreSQL, or introduce a dedicated vector system. The right decision depends on retrieval quality, access controls, scaling requirements and the cost of keeping multiple data stores synchronized.

An organization building an AI knowledge assistant may already store its documents, users and permissions in PostgreSQL. To make those documents searchable by meaning, the application needs embeddings. These are numerical representations of content that allow software to find semantically related passages.

One option is to store embeddings alongside application data using the pgvector extension. Another is to maintain a separate vector-search system. Both architectures can support retrieval-augmented generation (RAG).

The question is whether a separate database solves a measurable problem or introduces complexity that the application does not yet need.

What pgvector adds to PostgreSQL

PostgreSQL already provides relational storage, transactions, joins, indexing and full-text search. pgvector adds vector data types, similarity operators and approximate nearest-neighbor indexes, which find close matches quickly without checking every vector.

An application can store document chunks, their embeddings and associated metadata in PostgreSQL. When a user asks a question, the application creates an embedding of that question and searches for similar document embeddings. The retrieved passages can then provide context to a language model generating an answer.

pgvector does not generate embeddings, enforce the correctness of model-generated answers or automatically determine whether a document is safe for a particular user to read. Those remain responsibilities of the application and its security architecture.

Importantly, pgvector is an extension, not a PostgreSQL 19 feature. Its existing capabilities work across supported PostgreSQL versions, and the pgvector README lists support for PostgreSQL 13 and later, so check which versions your release supports. For what changes in PostgreSQL itself, see our article on PostgreSQL 19 and its release candidate.

Source: pgvector official documentation.

How an enterprise RAG application retrieves documents

Consider a hypothetical internal knowledge assistant used by Finance and Human Resources employees. The organization stores documents and access metadata in PostgreSQL. Each document is divided into searchable passages, with an embedding associated with each passage.

A typical retrieval operation has several stages.

1. Authenticate the user. The application establishes the user’s identity and authorized organizational context.

2. Determine the permitted document scope. The server identifies which documents the user is entitled to access, using trusted authorization data rather than user-supplied instructions.

3. Generate the question embedding. An embedding model converts the user’s question into the same compatible vector representation used for the stored passages.

4. Retrieve matching passages. PostgreSQL searches for semantically similar content while applying the appropriate document-access conditions.

5. Enforce the access boundary. The application verifies that only permitted content can be passed to the model. Database-side row-level security can provide another enforcement layer where correctly configured.

6. Generate the response. The language model uses authorized passages as supporting context. The application can retain source references for traceability.

Suppose a Finance employee asks about an expense-approval policy. A Human Resources document might be semantically similar, but similarity does not make that document authorized. The database query and surrounding application controls must prevent restricted material from entering the model’s context.

PostgreSQL row-level security

PostgreSQL row-level security (RLS) can restrict which records a database role may read or modify. It can help enforce tenant or document boundaries independently of ordinary application filtering.

However, enabling RLS does not automatically make every connection safe. Superusers and roles with BYPASSRLS bypass policies. Table owners normally bypass RLS unless FORCE ROW LEVEL SECURITY is configured. Applications also need to establish authorization context safely, especially when connections are pooled or reused.

RLS should be tested with realistic user roles, including negative tests proving that unauthorized documents cannot be retrieved. An ordinary WHERE tenant_id = ... clause is useful for query filtering, but should not be treated as a complete security boundary when the calling application can alter or omit it.

Source: PostgreSQL, Row Security Policies.

Exact search and approximate indexes solve different problems

By default, pgvector performs exact nearest-neighbor search. This finds the nearest matching vectors under the selected distance measure, providing a useful baseline against which approximate results can be evaluated. As vector collections and request volumes grow, exact search may become more expensive.

pgvector supports two principal approximate indexing methods.

Index	How it works	Important trade-off
HNSW	Organizes vectors into a navigable graph	Strong speed and recall characteristics for many workloads, with additional build time and memory requirements
IVFFlat	Groups vectors into lists and searches selected lists	Requires suitable training data and tuning of search breadth

Approximate indexes can return different results from exact search. That is why latency alone is an insufficient performance measure. Teams should also measure recall, which indicates how many expected nearest-neighbor results were retrieved compared with an exact-search baseline.

For an AI assistant, a faster result may be less useful if an important document is consistently omitted.

Source: pgvector, Indexing.

Filtering can affect retrieval quality

Enterprise searches rarely depend on vector similarity alone. Results may also be filtered by organization, document type, project or access scope. With approximate indexes, PostgreSQL can apply filtering after the index scan has selected candidates, and this can return fewer results than requested.

For example, if a search examines 40 candidates and only 10% satisfy a category filter, approximately four may remain on average. That is an illustration of selectivity, not a guaranteed outcome for every search.

pgvector introduced iterative index scans in version 0.8.0 on October 30, 2024. Iterative scans can continue examining more index candidates when filtering removes too many results, subject to configured resource and scan limits. Other approaches include ordinary PostgreSQL indexes, partial vector indexes and table partitioning, depending on query patterns. These mechanisms should be selected through measurement.

Tenants that share one approximate index can also affect each other. The pgvector documentation says vectors from one tenant can change recall and speed for other tenants, and recommends list partitioning or separate tables for tenant isolation.

A correctly enforced authorization filter must never be weakened merely to increase the number of search results. A retrieval system returning fewer authorized passages may produce a less complete answer. Returning unauthorized passages is a different and more serious failure.

Sources: pgvector changelog, pgvector filtering guidance and pgvector multitenancy.

Hybrid search combines different forms of relevance

Semantic similarity is useful when users describe a concept without using the exact wording found in a document. Keyword search remains important for identifiers, product names, policy numbers and technical terms.

PostgreSQL supports full-text search through facilities such as tsvector and tsquery. Applications can combine those results with pgvector similarity search. For example, a knowledge assistant searching for a specific incident number may benefit from exact text matching, while a broader troubleshooting question may benefit from semantic retrieval.

Ranked results can be combined using techniques such as reciprocal rank fusion, which merges two ranked lists by position, then optionally reranked using another relevance model. However, hybrid search does not guarantee better retrieval in every application. Teams should evaluate representative questions, expected documents and final ranking quality.

Sources: PostgreSQL full-text search and pgvector hybrid search.

When does a separate vector database become useful?

A dedicated vector system may become worthwhile when an application’s retrieval requirements exceed what its existing PostgreSQL environment can support effectively. Examples include independently scaling vector-search traffic, specialized distributed indexing, very large search collections or retrieval features that are unavailable in the chosen PostgreSQL deployment.

But moving embeddings to another system creates additional responsibilities.

Consider a document update. The application changes the source document in PostgreSQL. It must also regenerate affected embeddings and update the vector index. Until synchronization finishes, searches may retrieve outdated content.

Deletion creates a related problem. Removing a document from the transactional database must also remove or invalidate its vector representations.

Permission changes are particularly important. If a user’s access is revoked, stale access metadata in another search system must not allow restricted content to reach the model.

An architecture with two data stores therefore needs a reliable way to propagate changes, handle failures, retry safely and determine when search data is current. Change-data capture, which streams changes out of the database, transactional outbox patterns, which record the change event in the same transaction as the data, and event processing can help, but each requires implementation and operational ownership. The authoritative permission check should remain enforceable even when the search index is delayed.

These synchronization boundaries are part of the cost of adopting a separate vector system.

Embedding models introduce another migration boundary

An embedding is generated using a particular model and representation. Changing the embedding model may change vector dimensions, distributions and similarity behavior. Embeddings produced by incompatible models should not be combined as though their distances were directly comparable.

Organizations should record embedding-model identifiers, versions and relevant generation settings. A model migration may require generating new embeddings, rebuilding indexes and evaluating retrieval quality before switching production queries. During a transition, old and new representations may need to coexist.

pgvector also has indexing limits that depend on the representation. Its documented HNSW support includes vector values up to 2,000 dimensions and halfvec values up to 4,000 dimensions. These limits concern the relevant index representation, not a universal restriction on every possible storage or search strategy. The application’s embedding-model choice therefore affects index design.

Source: pgvector, Vector Types and Indexing Limits.

How should a team choose?

A useful evaluation compares the existing PostgreSQL approach with a separate vector system using the same representative workload.

Evaluation area	Question to answer
Retrieval quality	Are expected relevant passages consistently found?
Authorization	Can unauthorized documents ever reach the model context?
Performance	Does search latency meet the target under realistic concurrency?
Filtering	Do selective tenant and metadata conditions preserve acceptable recall?
Updates and deletions	How quickly does the search index reflect source changes?
Operations	What are the indexing, backup, monitoring and recovery requirements?
Scaling	Can retrieval demand grow without harming transactional workloads?
Cost	What is the combined infrastructure and maintenance expense?

The comparison should not assume that the most specialized technology is automatically the most suitable. A small or moderately sized application may find that PostgreSQL with pgvector meets its needs with fewer systems to manage. A larger application may justify an independent search tier when workload isolation, specialized features or independent scaling delivers measurable benefits. Those outcomes are workload-dependent and should be established through tests, not generic database-size thresholds.

Operations also include keeping the extension patched. The pgvector changelog records fixes for possible index corruption during HNSW vacuuming in version 0.8.3 on June 17, 2026, and for buffer overflows during IVFFlat index builds in versions 0.8.6 on July 29 (on 32-bit systems) and 0.8.7 on October 1, 2026. Teams should run a current patch release and test index maintenance, such as vacuuming and rebuilds, before relying on an index in production.

Source: pgvector, Changelog.

What the architecture decision comes down to

PostgreSQL and pgvector allow application records, embeddings, metadata and text search to remain within one database environment. This can simplify AI applications that already depend heavily on relational data. A separate vector system may provide valuable capabilities, but requires attention to synchronization, deletions, authorization and operational ownership.

Neither architecture automatically guarantees search relevance or secure retrieval.

Start with verified retrieval and access-control requirements. Use PostgreSQL with pgvector when it meets them effectively, and introduce a separate vector system when measurements justify the additional complexity.

---

References and further reading

1. pgvector, Official Repository. Supported vector types, similarity search, indexing, filtering and multitenancy.
2. pgvector, Changelog. Version history, iterative index scans and patch releases.
3. PostgreSQL, Row Security Policies. Database authorization behavior and bypass conditions.
4. PostgreSQL, Full Text Search. Keyword retrieval and ranking.
5. PostgreSQL, Full Text Search Introduction. The tsvector and tsquery types.
6. PostgreSQL, EXPLAIN. Execution-plan inspection and performance evaluation.
7. pgvector, Release and Security History. Extension releases and maintenance updates.

Sources verified November 6, 2026. pgvector releases often, and the 0.8.7 release on October 1, 2026 fixed an IVFFlat index build bug and is not presented as introducing the architectural capabilities discussed here, so check the sources above before you act. Performance and architecture guidance are analytical recommendations, not independent TechiesJournal benchmark results.