Choosing a vector database in 2026: pgvector vs the specialists

Retrieval-augmented generation (RAG) systems have moved from prototypes into production software. In 2026, choosing a vector database is no longer just about asking, “Can this store embeddings?”

The harder architecture questions are:

• How many vectors will exist after one or two years?

• What latency does the application need?

• How important are filtering, hybrid search, and multi-tenancy?

• Should embeddings live beside business data or in a dedicated retrieval platform?

• Who will operate the system?

For many applications, PostgreSQL with pgvector is enough. For others, specialized vector databases provide capabilities that justify running another production system.

The right choice depends on the retrieval workflow, not on which product has the largest benchmark number.

What a vector database actually does

Embedding models convert text, images, audio, or other data into numerical representations called vectors.

Example:

"How do I reset my password?" → [0.021, -0.143, 0.882, ...]

A traditional search engine mainly matches words and fields. Vector search finds items that are semantically close.

A typical RAG pipeline looks like this:

1. A user submits a question.

2. The application creates an embedding for that question.

3. A retrieval system finds relevant content.

4. A language model generates an answer using the retrieved context.

The database choice affects the retrieval layer: speed, filtering, scaling, operations, and cost.

Option 1: PostgreSQL + pgvector

PostgreSQL with the pgvector extension adds vector similarity search to a database many teams already use.

The main advantage is simplicity:

• Relational data and embeddings can live together.

• SQL handles joins and metadata filters naturally.

• Existing database skills and operational processes can be reused.

• A team avoids adding another infrastructure component.

For internal knowledge bases, customer support tools, and applications where search is one feature among many, this can be an excellent architecture.

A simple schema:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
    id bigserial PRIMARY KEY,
    title text NOT NULL,
    content text NOT NULL,
    category text,
    embedding vector(1536)
);

Insert a document with an embedding:

INSERT INTO documents (
    title,
    content,
    category,
    embedding
)
VALUES (
    'Password reset guide',
    'Users can reset passwords from account settings.',
    'support',
    '[0.021, -0.143, 0.882]'
);

A similarity search query:

SELECT
    id,
    title,
    content
FROM documents
ORDER BY embedding <=> '[0.019, -0.140, 0.879]'
LIMIT 5;

For larger datasets, approximate nearest-neighbor indexes are commonly used:

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

The HNSW index is popular because it often provides a strong balance between retrieval speed and search quality.

When pgvector is the right choice

pgvector is a strong fit when:

• PostgreSQL is already your application database.

• Retrieval is part of a larger transactional system.

• SQL joins are important.

• You need permissions and metadata filtering close to the data.

• Your vector collection is within a scale PostgreSQL can handle comfortably.

For example, a support application might store:

• customer accounts

• support tickets

• access permissions

• documentation

• embeddings

A single query can combine business rules with semantic search:

SELECT
    document_id,
    content
FROM knowledge_base
WHERE customer_plan = 'enterprise'
ORDER BY embedding <=> '[query vector]'
LIMIT 10;

This simplicity is difficult to beat.

Where pgvector becomes challenging

PostgreSQL is a general-purpose database. It was not designed exclusively for massive similarity-search workloads.

Challenges may appear with:

• hundreds of millions or billions of vectors

• very high query volume

• globally distributed retrieval systems

• specialized vector operations

• large-scale index management

These problems do not automatically mean “move away from PostgreSQL.” Good schema design, indexing, hardware choices, and query tuning can go a long way.

However, some teams eventually decide retrieval itself has become a core infrastructure product.

Option 2: Specialized vector databases

Dedicated vector databases focus primarily on similarity search.

Examples include:

• Pinecone

• Qdrant

• Weaviate

They are not replacements for PostgreSQL in every architecture. They are specialized tools for workloads where retrieval is a major engineering concern.

Pinecone: managed retrieval infrastructure

A managed vector database reduces operational work.

Typical advantages:

• hosted infrastructure

• provider-managed scaling

• vector-focused APIs

• fewer database operations tasks

The trade-off is cost, dependency on an external platform, and less control over infrastructure.

A typical Python workflow uses the official client library:

from pinecone import Pinecone

pc = Pinecone(api_key="YOUR_API_KEY")

index = pc.Index("support-documents")

index.upsert(
    vectors=[
        {
            "id": "doc-001",
            "values": [0.021, -0.143, 0.882],
            "metadata": {
                "category": "support"
            }
        }
    ]
)

Always verify SDK usage against the current official documentation because cloud SDKs evolve independently from database concepts.

Qdrant: vector search with deployment flexibility

Qdrant focuses on vector collections, metadata filtering, and flexible deployment options.

It can be deployed as a managed service or self-hosted, making it attractive for teams that want more control.

Example insertion:

from qdrant_client import QdrantClient
from qdrant_client.models import PointStruct

client = QdrantClient(
    url="http://localhost:6333"
)

client.upsert(
    collection_name="documents",
    points=[
        PointStruct(
            id=1,
            vector=[0.021, -0.143, 0.882],
            payload={
                "topic": "security"
            }
        )
    ]
)

Qdrant is often considered when vector search is important enough to deserve dedicated infrastructure.

Weaviate: search-oriented application features

Weaviate focuses on AI search workflows, including:

• vector search

• hybrid search

• filtering

• integrations for AI applications

The benefit is having retrieval features available without assembling everything yourself.

The cost is operational complexity: every additional production system requires monitoring, upgrades, security reviews, and incident planning.

pgvector vs specialized VectorDB systems

Requirement	pgvector	Specialized vector database
Existing PostgreSQL application	Excellent fit	Usually unnecessary
SQL joins with business data	Excellent	Usually limited
Simple RAG workflows	Excellent	Good
Very large vector collections	Possible with planning	Often stronger
Avoiding new infrastructure	Best choice	Usually worse
Managed operations	Team responsibility	Often included
Retrieval-specific features	Build around SQL	Usually built in

Hybrid retrieval is becoming the default

Pure vector search is not always enough.

Consider a query containing:

CVE-2024-3094

An embedding model understands meaning, but exact identifiers are where keyword search often performs better.

Keyword search remains valuable for:

• product IDs

• error messages

• version numbers

• legal references

• security identifiers

Modern Retrieval workflows often combine:

• vector similarity

• keyword search

• metadata filtering

• reranking models

The goal is not replacing traditional search. It is combining multiple signals.

Performance basics: indexes matter

Without an index, similarity search may require comparing a query against every stored vector.

Approximate nearest-neighbor algorithms reduce this work.

Two common approaches are:

HNSW

Hierarchical Navigable Small World graphs provide:

• fast queries

• strong recall

• good performance across many workloads

Trade-offs:

• higher memory usage

• longer index construction time

IVFFlat

Inverted File indexes group vectors into clusters.

Trade-offs:

• lower memory requirements

• more tuning

• performance depends heavily on configuration

Benchmark with your own data. Generic rankings rarely represent your exact workload.

Cherry on the cake: the XZ Utils supply-chain lesson

A surprising infrastructure lesson came from CVE-2024-3094, a malicious backdoor discovered in XZ Utils, a widely used compression library in the Linux ecosystem.

The incident showed that modern software systems depend on large chains of components. The issue was not a database performance failure; it was a supply-chain trust problem.

AI retrieval systems have similar dependency layers:

• database extensions

• SDKs

• embedding libraries

• container images

• deployment tools

• monitoring systems

A practical lesson is to treat retrieval infrastructure like any other production software:

• pin and review dependencies

• use vulnerability scanning

• monitor upstream projects

• maintain a software bill of materials where appropriate

Fast retrieval is useful only when the surrounding system is trustworthy.

The hidden cost of embeddings

Embeddings look small because they are arrays of numbers, but scale changes the economics.

A 1536-dimensional embedding stored as 32-bit floating point values requires approximately:

1536 × 4 bytes = 6144 bytes

That is about 6 KB before adding:

• indexes

• metadata

• database overhead

• replication

• backups

One million vectors can require multiple gigabytes. Hundreds of millions of vectors can become a major storage and operations challenge.

Costs increase further when systems add:

• multiple embeddings per document

• smaller document chunks

• duplicate content

• larger embedding dimensions

Good retrieval architecture optimizes both quality and cost.

Production checklist

Before choosing a vector database, measure:

Data

• How many vectors exist today?

• How many will exist in two years?

• Are vectors deleted or only added?

• Are multiple embeddings stored per item?

Search

• What latency target do users expect?

• Is hybrid retrieval required?

• Is reranking needed?

• How important is recall quality?

Operations

• Who manages upgrades?

• What is the backup strategy?

• Is self-hosting required?

• How quickly must failures recover?

Security

• Should every user retrieve the same documents?

• Are permissions applied before retrieval?

• Are embeddings created from sensitive data?

Final recommendation

There is no universal winner.

Choose pgvector when vectors are an important feature inside a larger PostgreSQL application.

Choose a specialized vector database when retrieval architecture has become a central engineering challenge and you need dedicated scaling, features, or operations.

Start with your actual workload:

• measure latency

• estimate vector growth

• test realistic queries

• compare operational costs

Your next step: take one real RAG workflow, estimate its vector count and query volume, then build a small comparison using pgvector and one specialized VectorDB option with your own data before committing to a long-term design.