PostgreSQL + pgvector: Do You Really Need a Vector Database?

Vector databases have become a standard part of conversations about RAG, semantic search, and AI applications.

The usual architecture looks like:

Application
    ├── PostgreSQL
    └── Vector Database

But if your application already uses PostgreSQL, adding another database is not always necessary.

With pgvector, PostgreSQL can store embeddings and perform exact or approximate vector similarity search alongside normal relational data.

For many applications, a simpler architecture is possible:

Application
      ↓
PostgreSQL + pgvector
      ↓
Relational Data + Embeddings

The real question is not whether a dedicated vector database is more specialized. It is whether your workload actually needs one.

What Is pgvector?

pgvector is an open-source PostgreSQL extension for vector similarity search.

After enabling it:

CREATE EXTENSION vector;

you can store embeddings directly in PostgreSQL:

CREATE TABLE documents (
    id BIGSERIAL PRIMARY KEY,
    content TEXT NOT NULL,
    embedding VECTOR(1536)
);

The embedding becomes another column attached to the same row as your application data.

You can then perform nearest-neighbor searches:

SELECT id, content
FROM documents
ORDER BY embedding <=> $1
LIMIT 10;

pgvector supports multiple distance functions, including cosine distance, L2 distance, and inner product.

Without an approximate index, pgvector performs exact nearest-neighbor search. For larger workloads, it supports HNSW and IVFFlat approximate indexes.

Why Keeping Vectors in PostgreSQL Is Attractive

Imagine a SaaS application already stores:

Users
Organizations
Documents
Permissions
Metadata

in PostgreSQL.

You now want semantic document search.

One option is:

PostgreSQL
     ↓
Document Metadata

Vector Database
     ↓
Document Embeddings

Now the application needs to keep two systems synchronized.

With pgvector:

PostgreSQL
     ↓
┌─────────────────────┐
│ Document            │
│ Content             │
│ Tenant ID           │
│ Permissions         │
│ Metadata            │
│ Embedding           │
└─────────────────────┘

The relational record and embedding can live together.

That can significantly simplify the first version of an AI feature.

Filtering Is Where PostgreSQL Becomes Especially Useful

Vector search rarely happens without filters.

A multi-tenant SaaS application may need:

Find documents semantically similar to this query, but only inside the current organization.

With PostgreSQL:

SELECT id, content
FROM documents
WHERE organization_id = $1
ORDER BY embedding <=> $2
LIMIT 10;

You can combine semantic similarity with normal SQL conditions:

tenant_id
document_type
created_at
status
permissions
category

This is useful when vector search is only one part of a larger relational query.

You can also use normal PostgreSQL indexes on filter columns and use partitioning or partial vector indexes for appropriate workloads.

Exact Search vs Approximate Search

By default, pgvector can compare the query vector against stored vectors exactly.

Conceptually:

Query Vector
     ↓
Compare Against Candidate Vectors
     ↓
Calculate Distance
     ↓
Sort
     ↓
Return Nearest Results

Exact search gives perfect recall, but the cost increases as the dataset grows.

For larger datasets, approximate nearest-neighbor indexes trade some recall for faster queries.

pgvector currently supports two primary ANN index types:

HNSW
IVFFlat

HNSW

HNSW builds a multilayer graph used to find nearby vectors efficiently.

For cosine distance:

CREATE INDEX documents_embedding_hnsw
ON documents
USING hnsw (embedding vector_cosine_ops);

HNSW generally provides a strong speed/recall trade-off, but it takes longer to build and uses more memory than IVFFlat.

It can also be created before the table contains data because it does not require a training phase.

For many pgvector workloads, HNSW is a practical starting point when approximate search becomes necessary.

IVFFlat

IVFFlat divides vectors into lists and searches only a subset of those lists.

CREATE INDEX documents_embedding_ivfflat
ON documents
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);

Compared with HNSW, IVFFlat generally builds faster and uses less memory, but offers a weaker query speed/recall trade-off.

It also needs tuning around the number of lists and probes, and the index should be created after the table has enough representative data.

Do not choose an ANN index just because it exists. Measure exact search first, then benchmark HNSW or IVFFlat against your actual dataset and recall requirements.

pgvector Fits Naturally Into RAG

A simple RAG system can use PostgreSQL for both application data andretrieval:

Documents
    ↓
Chunking
    ↓
Embedding Model
    ↓
PostgreSQL + pgvector
    ↓
Similarity Search
    ↓
Relevant Chunks
    ↓
LLM
    ↓
Answer

A table might contain:

CREATE TABLE document_chunks (
    id BIGSERIAL PRIMARY KEY,
    document_id BIGINT NOT NULL,
    organization_id BIGINT NOT NULL,
    content TEXT NOT NULL,
    embedding VECTOR(1536)
);

Retrieval can combine tenant filtering and semantic search in one query:

SELECT id, document_id, content
FROM document_chunks
WHERE organization_id = $1
ORDER BY embedding <=> $2
LIMIT 8;

For an existing PostgreSQL-backed SaaS product, this can be much easier to operate than introducing another database immediately.

Hybrid Search Is Possible Too

Semantic similarity is not always enough.

Users may search for exact product names, error codes, identifiers, or technical terms where lexical matching is valuable.

PostgreSQL already has full-text search, and pgvector can be used alongside it.

Conceptually:

User Query
   ├── Full-Text Search
   └── Vector Search
            ↓
       Combine / Rerank
            ↓
          Results

This allows you to build hybrid retrieval without immediately adding both a vector database and a separate search engine.

Whether PostgreSQL alone is sufficient still depends on the quality and scale requirements of your search workload.

Where pgvector Starts Getting More Complicated

Using PostgreSQL does not make vector-search problems disappear.

Approximate vector search combined with metadata filters requires careful design.

With a global ANN index, filtering may occur after candidate vectors are retrieved. If only a small percentage of those candidates satisfy the filter, the query may return fewer useful results than expected.

pgvector provides several tools for these cases:

• Normal indexes on filter columns.

• Partial vector indexes.

• Table partitioning.

• Higher HNSW search parameters.

• Iterative index scans.

For example:

SET hnsw.iterative_scan = strict_order;

Iterative scans allow pgvector to continue scanning the approximate index when filtering removes too many initial candidates.

For multi-tenant systems with strict isolation or very different tenant sizes, partitioning or separate tables may also be worth considering.

This is an area where benchmarking with realistic filters matters much more than a generic vectors-per-table number.

What Does a Dedicated Vector Database Give You?

A dedicated vector database is designed primarily around vector retrieval.

Depending on the product, it may provide specialized capabilities around:

Large distributed vector indexes
Horizontal scaling
Vector-specific filtering
Index management
Replication
High-throughput ingestion
Operational tooling

The trade-off is another system.

Your architecture becomes:

Application
    ├── PostgreSQL
    │      ↓
    │ Relational Data
    │
    └── Vector Database
           ↓
       Embeddings

Now you need to think about:

Data synchronization
Retries
Consistency
Backups
Permissions
Monitoring
Network failures
Operational cost

That complexity may be completely justified at sufficient scale.

But it should solve a real problem.

PostgreSQL + pgvector vs Dedicated Vector Database

Area PostgreSQL + pgvector Dedicated Vector Database

Existing relational Excellent fit Usually stored data elsewhere

Operational complexity Lower if PostgreSQL Adds another system already exists

SQL joins and filters Native Product-dependent

Transactions Same PostgreSQL Cross-system transaction model coordination may be needed

Vector specialization Good Usually stronger

Horizontal vector Requires PostgreSQL Often a core feature scaling scaling strategy

Small/medium RAG Strong fit Often unnecessary workloads

Very large vector-first May require more Often better suited workloads engineering

The decision is not about which technology is universally better.

It is about whether vector search is a feature of your application or one of its primary infrastructure workloads.

When pgvector Is Probably Enough

PostgreSQL + pgvector is a strong starting point when:

You Already Use PostgreSQL

Adding one extension is operationally simpler than adding another database.

Vector Search Is One Product Feature

Examples include:

Semantic document search
RAG over internal content
Recommendation features
Similarity lookup
AI agent memory

Relational Filtering Matters

Your retrieval frequently depends on tenant IDs, permissions, categories, dates, or other relational fields.

Your Dataset Is Manageable

The workload fits comfortably within a PostgreSQL architecture that your team can scale and operate.

Your Team Values Simplicity

One database means fewer systems to deploy, monitor, secure, back up, and debug.

When a Dedicated Vector Database May Make Sense

Consider a specialized system when vector retrieval itself becomes a major infrastructure problem.

Signals include:

Vector Scale Dominates the Database

You have a very large vector corpus and vector indexing is becoming one of the primary storage and compute workloads.

You Need Independent Vector Scaling

Your relational workload and vector workload need to scale very differently.

Search Performance Requirements Are Strict

You need consistently low latency under high vector-query concurrency and pgvector is no longer meeting tested requirements.

Complex Filtered ANN Is Central to the Product

Your application relies heavily on large-scale vector search with complex metadata filtering, and a specialized engine performs materially better for your workload.

Operational Separation Is Valuable

A dedicated team or platform owns search infrastructure and benefits from scaling it independently.

The key phrase is measured requirement.

Do not migrate because a benchmark from an unrelated dataset says another database is faster.

A Practical Evolution Path

A startup building RAG does not need to make the final database decision on day one.

Stage 1

Start with:

Application
      ↓
PostgreSQL + pgvector

Keep relational data and embeddings together.

Stage 2

Add the right indexes:

B-tree / GIN indexes
        +
HNSW or IVFFlat

Measure latency and recall.

Stage 3

Optimize:

Query tuning
Partitioning
Caching
Read replicas
Index tuning

Stage 4

Only if vector search becomes a proven bottleneck:

Application
    ├── PostgreSQL
    └── Dedicated Vector Infrastructure

At that point, you are solving a measured problem instead of predicting one.

Do Not Compare Only Raw Vector Search Speed

A dedicated vector database may win a vector-only benchmark while still making the complete application architecture more complicated.

Measure the full request:

User Query
    ↓
Authorization
    ↓
Metadata Filtering
    ↓
Vector Retrieval
    ↓
Document Fetching
    ↓
Reranking
    ↓
LLM

If vector search takes 30 ms but the LLM takes 1.5 seconds, reducing vector search to 15 ms may not materially improve the user experience.

Likewise, if maintaining a second datastore adds synchronization bugs, operational simplicity may be worth more than benchmark performance.

Optimize the system, not one component in isolation.

Common Mistakes

Adding a Vector Database Automatically

Using embeddings does not automatically require a dedicated vector database.

Ignoring Metadata Filters

Benchmark with the tenant, permission, and category filters your production queries actually use.

Creating ANN Indexes Too Early

Exact search may be perfectly adequate for smaller datasets. Measure first.

Treating Recall as Binary

Approximate search trades recall for performance. Test whether the returned results are good enough for your application.

Ignoring Storage and Index Memory

Embeddings and ANN indexes consume meaningful storage and memory. Include them in capacity planning.

Splitting Data Without a Synchronization Strategy

If PostgreSQL owns documents and another database owns embeddings, define how updates and deletes remain consistent.

So, Do You Really Need a Vector Database?

Often, no.

If PostgreSQL is already the core database for your application, pgvector can provide a clean path to semantic search, RAG, recommendations, and other embedding-based features without adding another datastore.

Start there when it fits.

Move to dedicated vector infrastructure when real scale, latency, filtering, or operational requirements justify the additional complexity.

The architecture should evolve because your workload demands it, not because every AI diagram includes a box labeled "Vector Database."

Conclusion

pgvector turns PostgreSQL into a capable vector search system while preserving the relational features developers already rely on.

For many applications, especially existing SaaS products adding RAG or semantic search, PostgreSQL + pgvector is a practical first architecture.

Use exact search while it is sufficient. Add HNSW or IVFFlat when measurements justify approximate search. Benchmark with real metadata filters, query patterns, and concurrency.

A dedicated vector database is valuable when vector search becomes large or specialized enough to deserve independent infrastructure.

Until then, the simplest database architecture may be the better one.