pgvector vs Pinecone: Which One Should You Use in 2026?

Most teams building their first RAG application already have PostgreSQL running. They have backups, monitoring, and on-call set up for it. The idea of adding a separate vector database, paying for another service, and learning another API is not appealing.

So they look at pgvector. And they should. For a lot of use cases, pgvector is genuinely the right choice.

But there is a point where pgvector stops being enough. And teams who miss that point end up with slow queries, degraded recall, and a migration they have to do under pressure.

I want to give you the honest comparison here. Not the version where one product wins cleanly, but the version where you understand exactly when each one makes sense for your situation.

The Short Version

If you want to skip the detail, here it is:

Use pgvector if you are already on Postgres, your dataset is under 1 to 2 million vectors, and you do not want to manage another service.

Use Pinecone if you need a fully managed vector database, your dataset is large, your QPS is high, and you want predictable latency without tuning anything.

If cost is the main reason you are considering pgvector over Pinecone, also look at Qdrant. Self-hosted Qdrant is often a better third option at scale than either one.

What Each One Is

pgvector

pgvector is a PostgreSQL extension. It adds a vector data type, three distance operators, and two index types (HNSW and IVFFlat) to a regular Postgres instance. Your vectors live in a table column next to your users, products, and orders. You query them with SQL.

It is open source, free, and works on PostgreSQL 12 or later. Most managed Postgres providers support it: Supabase, AWS RDS, Google Cloud SQL, and Neon all have pgvector available.

For the full setup guide and performance tuning details, see the pgvector complete guide.

Pinecone

Pinecone is a fully managed vector database. You cannot self-host it. You use their cloud service, pay a monthly bill, and they handle all the infrastructure.

It launched in 2021 and was one of the first databases built specifically for vector similarity search. The API is clean, the documentation is thorough, and you can have a working search pipeline in about twenty minutes.

Pinecone has two modes:

Serverless uses shared infrastructure. You pay per read unit, write unit, and GB stored. No idle cost. Good for development and workloads with unpredictable query volume.

Pod-based gives you dedicated compute. You pay for the pod continuously. Better for high-QPS production workloads where you need consistent latency.

Setup and Developer Experience

This is where pgvector wins clearly for teams already on Postgres.

pgvector setup

-- Enable the extension
CREATE EXTENSION IF NOT EXISTS vector;

-- Add a vector column to an existing table
ALTER TABLE documents ADD COLUMN embedding vector(1536);

-- Create an HNSW index
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- Query it
SELECT id, content, 1 - (embedding <=> $1::vector) AS similarity
FROM documents
ORDER BY embedding <=> $1::vector
LIMIT 10;

That is it. If you have Postgres, you run one CREATE EXTENSION command and you are done. No new accounts, no API keys, no billing setup, no new SDK to learn. Your vectors live in the same database you already query. You can join them to other tables in the same query.

Pinecone setup

from pinecone import Pinecone

# Initialize client
pc = Pinecone(api_key="your-api-key")

# Create an index
pc.create_index(
    name="my-index",
    dimension=1536,
    metric="cosine",
    spec=ServerlessSpec(cloud="aws", region="us-east-1")
)

# Connect to the index
index = pc.Index("my-index")

# Upsert vectors
index.upsert(vectors=[
    {"id": "doc-1", "values": embedding_list, "metadata": {"text": "..."}}
])

# Query
results = index.query(
    vector=query_embedding,
    top_k=10,
    include_metadata=True
)

Pinecone is also easy to set up. You need an account, an API key, and their Python SDK. The operations are simple and the SDK is well-documented. But you are now outside your Postgres world. Your vectors live separately from your application data. Joins require application-level code.

Winner: pgvector for teams on Postgres. Pinecone wins for teams starting fresh who do not want to manage any database at all.

Performance

This is the comparison that most articles get wrong by treating it as a simple race. The real question is: performance at what scale, on what hardware?

pgvector performance characteristics

With a properly configured HNSW index, pgvector handles similarity search in single-digit milliseconds for datasets up to about 500K vectors on a standard instance. At 1 million vectors, you are still looking at under 20ms p99 with a good index configuration.

-- Good HNSW settings for production
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (
    m = 16,              -- higher = better recall, more memory
    ef_construction = 64 -- higher = better recall, slower index build
);

-- Set ef_search at query time for recall vs speed trade-off
SET hnsw.ef_search = 100;

The problem is that pgvector shares CPU and memory with every other query hitting your Postgres instance. When a heavy analytical query runs, your vector search latency spikes. When you load a bulk import, index maintenance competes with live queries. You are managing one system, but that one system is handling multiple competing workloads.

At 5 million or more vectors, pgvector's HNSW implementation also starts to show its limits. Index build times grow significantly. Memory pressure increases. Recall can drop under load if you do not carefully tune ef_search.

Pinecone performance characteristics

Pinecone's infrastructure is purpose-built for vector search. There are no competing workloads. The entire system is optimized for one thing.

In Pinecone's own published benchmarks, pod-based indexes deliver under 10ms p99 latency at hundreds of QPS for datasets in the tens of millions of vectors. Serverless is competitive at lower QPS but has more latency variability on cold queries.

The main advantage is consistency. Pinecone's latency is predictable. pgvector's latency depends on what else is happening on your Postgres instance.

Honest benchmark numbers

pgvector numbers assume a dedicated Postgres instance with no competing workload. Real-world numbers in a shared environment will be higher.

Winner: Pinecone at large scale. At small to medium scale (under 2M vectors), pgvector is competitive, especially on dedicated hardware.

Filtering

Filtering is the most important practical difference between the two.

When you run a vector search, you almost always want to filter. Not just "find the 10 most similar documents" but "find the 10 most similar documents that belong to this user and were created in the last 30 days."

pgvector filtering

pgvector filters using regular PostgreSQL WHERE clauses. This is both its biggest strength and its biggest weakness.

The strength: you can filter on any indexed column with full SQL expressiveness.

-- Filter by user and date with vector search
SELECT id, content, 1 - (embedding <=> $1::vector) AS similarity
FROM documents
WHERE user_id = 42
  AND created_at > NOW() - INTERVAL '30 days'
  AND category = 'technical'
ORDER BY embedding <=> $1::vector
LIMIT 10;

The weakness: pgvector applies the filter and the vector search separately, not together. The planner either scans the filtered rows and does a sequential vector scan, or it uses the HNSW index and then filters the results. Neither approach is ideal when your filter reduces the dataset to a small fraction.

If you filter to 1,000 rows out of 1 million, the HNSW index scanned the whole index to get 1,000 candidates, then kept only the ones passing the filter. For heavy filtering scenarios, this degrades to near-sequential scan performance.

Postgres 16 introduced a partial index approach that helps:

-- Partial index for a specific user
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WHERE user_id = 42;

This works for known, static filter values but does not generalize to dynamic filters.

Pinecone filtering

Pinecone has metadata filtering built into the query API. You pass a filter object alongside the vector query.

results = index.query(
    vector=query_embedding,
    top_k=10,
    filter={
        "user_id": {"$eq": 42},
        "category": {"$in": ["technical", "reference"]},
        "created_at": {"$gt": 1700000000}
    },
    include_metadata=True
)

Pinecone applies the filter in parallel with the vector search using its own internal indexing on the metadata fields. For simple equality and range filters, this is reliable.

The limitation: Pinecone's filtering is not as expressive as SQL. No joins, no subqueries, no arbitrary expressions. Complex filters may require you to pre-compute and store the values you need as metadata.

Winner: draw, with a caveat. For simple filters on metadata you control, Pinecone handles them more reliably at scale. For complex filters using joins or existing application data, pgvector's SQL approach is more flexible.

Hybrid Search

Hybrid search combines dense vector search with keyword (sparse) search. It is better than either alone for most RAG applications. Queries with specific terminology, proper nouns, or codes benefit from keyword matching that pure vector similarity misses.

pgvector hybrid search

pgvector does not have native sparse vector support. You do hybrid search by combining pgvector with PostgreSQL's full-text search using tsvector.

-- Hybrid search: combine vector similarity with full-text ranking
WITH vector_results AS (
    SELECT id, 1 - (embedding <=> $1::vector) AS vector_score
    FROM documents
    ORDER BY embedding <=> $1::vector
    LIMIT 50
),
text_results AS (
    SELECT id, ts_rank(search_vector, plainto_tsquery('english', $2)) AS text_score
    FROM documents
    WHERE search_vector @@ plainto_tsquery('english', $2)
    LIMIT 50
)
SELECT
    COALESCE(v.id, t.id) AS id,
    COALESCE(v.vector_score, 0) * 0.7 + COALESCE(t.text_score, 0) * 0.3 AS hybrid_score
FROM vector_results v
FULL OUTER JOIN text_results t ON v.id = t.id
ORDER BY hybrid_score DESC
LIMIT 10;

This works, but it is complex SQL. You are managing two separate score systems and manually implementing reciprocal rank fusion or a weighted combination. You also need to maintain a tsvector column separately.

Pinecone hybrid search

Pinecone Serverless supports hybrid search using sparse-dense vectors. You store both a dense embedding and a sparse vector (typically BM25 weights) for each document.

from pinecone_text.sparse import BM25Encoder

# Encode sparse vectors
bm25 = BM25Encoder()
bm25.fit(corpus)
sparse_vectors = bm25.encode_documents(corpus)

# Upsert with both dense and sparse
index.upsert(vectors=[{
    "id": doc_id,
    "values": dense_embedding,        # dense vector
    "sparse_values": sparse_vector,   # sparse BM25 vector
    "metadata": {"text": doc_text}
}])

# Hybrid query
results = index.query(
    vector=query_dense,
    sparse_vector=query_sparse,
    top_k=10,
    alpha=0.75  # weight toward dense
)

Pinecone's hybrid search is cleaner to implement than pgvector's. The alpha parameter controls the balance between dense and sparse in a single line.

Winner: Pinecone for hybrid search. The implementation is cleaner and integrated natively. pgvector hybrid search requires more application code and is harder to tune.

Cost Comparison

This is where most teams make their decision.

pgvector cost

pgvector itself is free. You pay for the Postgres instance.

The important caveat: this assumes your Postgres instance is used primarily for vector search. If you are adding vector search to an existing Postgres database, the marginal cost of pgvector is near zero. You are already paying for that instance.

Pinecone cost

Pinecone Serverless pricing (2026) is based on read units (RU), write units (WU), and storage.

• Read: ~$0.040 per 1M read units
• Write: ~$2.00 per 1M write units
• Storage: ~$0.030 per GB per month

At 1536 dimensions, 1 million vectors takes roughly 6 GB. Each query consumes roughly 6 to 20 read units depending on dimensions and filter complexity.

Pod-based Pinecone is priced differently. A p1.x1 pod (the smallest) runs about $70 per month and handles roughly 1 million vectors. Pods scale up from there.

Cost verdict

Winner: pgvector if you are already on Postgres. Pinecone gets expensive at scale. If you need managed + large scale, run the numbers for Qdrant Cloud before committing to Pinecone.

When pgvector Breaks Down

pgvector has real limits. Knowing them in advance lets you plan for them instead of hitting them by surprise.

Scale limit around 1 to 2 million vectors. HNSW in pgvector works well up to this range on reasonable hardware. Above it, index build times grow substantially, memory pressure increases, and query latency starts degrading. Some teams push to 5 million with heavy optimization, but it requires significant effort.

Recall degrades under load. When your Postgres instance is under CPU pressure, the query planner may choose a suboptimal execution plan for vector queries. Recall can drop because ef_search is effectively reduced by resource contention.

No built-in replication for vector workloads. Standard Postgres streaming replication works, but there is no read replica routing that is aware of vector query patterns. High-read workloads hit the primary.

Filtered search is not efficient for selective filters. If you filter to a small subset of your data (say, 1% of rows), pgvector cannot efficiently scan only that subset using the HNSW index. A dedicated vector database with native filtered search handles this much better.

No built-in sparse vector support. Hybrid search requires a custom implementation.

When Pinecone Breaks Down

Pinecone has its own limitations.

Cost at scale. The pricing works at small to medium scale. At tens of millions of vectors with high query rates, the bill becomes significant. This is the most common reason teams leave Pinecone.

No joins with application data. Your vectors live in Pinecone. Your application data lives in Postgres or another database. Combining them requires application-level code: fetch from Pinecone, then fetch from Postgres using the IDs. Two round trips for every search.

Metadata filter limits. Pinecone's filter syntax covers common cases but is not as expressive as SQL. Complex business logic in filters often requires pre-computing and storing derived values as metadata.

No self-hosting option. If you need to keep data on your own infrastructure for compliance or security reasons, Pinecone is not an option.

Vendor lock-in. Migrating away from Pinecone means exporting all your vectors and rebuilding your index in a new system. There is no standard format.

The Decision Framework

Here is how to actually make this decision.

Start with pgvector if all of these are true:

• You are already running PostgreSQL
• Your dataset is under 1 million vectors for now
• You do not expect to exceed 5 million vectors within 12 months
• Your QPS requirement is under 100 queries per second
• Your team does not want to manage another service

Start with Pinecone if any of these are true:

• You need a fully managed service with zero infrastructure to operate
• Your dataset is 5 million or more vectors
• You need consistent sub-10ms latency at high QPS
• You are not running Postgres and do not want to start

Consider self-hosted Qdrant instead of Pinecone if:

• Cost is the main reason you are looking at pgvector over Pinecone
• You have DevOps capacity to run a container
• You need native hybrid search without complex SQL
• You need better filtered search than pgvector provides

Migration Path (pgvector to Pinecone)

If you start with pgvector and later need to migrate to Pinecone, the path is straightforward.

import psycopg2
from pinecone import Pinecone, ServerlessSpec

# Connect to Postgres and export vectors
conn = psycopg2.connect("postgresql://...")
cur = conn.cursor()
cur.execute("SELECT id, content, embedding FROM documents")
rows = cur.fetchall()

# Set up Pinecone
pc = Pinecone(api_key="your-api-key")
pc.create_index(
    name="migrated-index",
    dimension=1536,
    metric="cosine",
    spec=ServerlessSpec(cloud="aws", region="us-east-1")
)
index = pc.Index("migrated-index")

# Upload in batches
batch_size = 100
for i in range(0, len(rows), batch_size):
    batch = rows[i:i + batch_size]
    vectors = [
        {
            "id": str(row[0]),
            "values": row[2],           # the vector from pgvector
            "metadata": {"text": row[1]}
        }
        for row in batch
    ]
    index.upsert(vectors=vectors)
    print(f"Uploaded {i + batch_size} of {len(rows)}")

print("Migration complete")

The migration is basically: read vectors out of Postgres, write them into Pinecone. The hard part is updating your application code to use the Pinecone SDK instead of SQL for similarity search queries.

Summary

pgvector and Pinecone are not really competitors for most teams. They serve different situations.

pgvector is the right default for teams already on Postgres with datasets under 1 to 2 million vectors. The integration is zero-friction, the cost is minimal, and the performance is sufficient for the vast majority of RAG applications. You stay in the SQL world you already know.

Pinecone is the right choice when you want a purpose-built managed service and your scale or QPS requirements are beyond what pgvector handles well. You pay for the convenience, the consistency, and the performance.

The mistake to avoid is migrating to Pinecone prematurely. A lot of teams do it because they assume they will need it, pay for months of Pinecone bills, and eventually realize pgvector would have been fine.

If you hit the limits of pgvector and cost is a concern, run the Qdrant numbers before defaulting to Pinecone. At scale, self-hosted Qdrant often provides better performance than pgvector and significantly lower cost than Pinecone.

Related Reading

• pgvector Complete Guide: Vector Search in PostgreSQL
• Pinecone vs Qdrant: Which Vector Database Should You Use?
• How to Choose a Vector Database
• Vector Database vs Traditional Database
• What Is a Vector Database?
• RAG Architecture Explained