pgvector vs Pinecone in 2026: Benchmarks, Cost, and When to Use Each

What pgvector and Pinecone Actually Are

The comparison starts with architecture, because these two technologies are not competing on the same plane. pgvector is an open-source PostgreSQL extension — not a separate database, not a new service, just an extension that adds a vector data type and approximate nearest-neighbour search to an existing PostgreSQL deployment. Your application data and vector embeddings live in the same database.

You keep existing backups, replication, monitoring, and operational runbooks. The extension adds three distance operators — <-> for Euclidean, <=> for cosine, <#> for inner product — and two index types: IVFFlat (inverted file, simpler to build, lower recall) and HNSW (Hierarchical Navigable Small World, higher recall at comparable query times, the right default for most workloads). Pinecone is a fundamentally different architecture: a purpose-built, fully managed vector database delivered as a SaaS API.

You send embeddings and metadata to Pinecone's API; Pinecone handles indexing, sharding, replication, scaling, and availability. You get similarity search results back through an HTTP client. The difference matters for how you think about the decision: pgvector extends something you already have.

Pinecone asks you to add something new — a new vendor, a new billing relationship, a new failure mode, a new monitoring surface.

-- pgvector setup: CREATE EXTENSION is the entire infrastructure change
CREATE EXTENSION IF NOT EXISTS vector;

-- Store embeddings alongside application data in the same table
ALTER TABLE documents ADD COLUMN embedding vector(1536);

-- Create HNSW index (pgvector 0.5+) — the index type that closed the recall gap
-- m=16 (graph connectivity), ef_construction=64 (build-time quality)
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- Query: semantic similarity search (cosine distance)
-- SET hnsw.ef_search controls recall vs. speed trade-off at query time
SET hnsw.ef_search = 100;

SELECT
  id,
  title,
  1 - (embedding <=> $1) AS similarity
FROM documents
ORDER BY embedding <=> $1
LIMIT 10;

Related: what's new in PostgreSQL 18, our AI data infrastructure service

How the Performance Gap Narrowed Since 2023

Two years ago, pgvector's IVFFlat index produced meaningfully lower recall than dedicated vector databases at equivalent query latency. 0, May 2023) changed that. HNSW uses a multi-layer graph structure that allows approximate nearest-neighbour search to skip most of the index during traversal — producing substantially better recall-vs-speed trade-offs than IVFFlat.

With ef_search set to 100, HNSW on pgvector reaches 97–99% recall on standard benchmark datasets (ANN Benchmarks, 1M vectors, 1536 dimensions), which is comparable to Pinecone's production recall levels. The m parameter (graph connectivity, default 16) and ef_construction (build-time quality, default 64) trade index build time and memory for recall — higher values improve recall at the cost of a larger index. For most production workloads, m=16 and ef_construction=64 with ef_search=100 at query time deliver recall competitive with dedicated vector databases.

The second change is PostgreSQL 18's 20–30% short-query throughput improvement for OLTP workloads (GA since September 2025) — embedding lookup queries are short queries that benefit directly. 5x higher query throughput and 79% lower cost than Pinecone when self-hosted, and can serve 100M+ vectors without requiring the full index to fit in RAM, closing a major gap at large scale.

-- HNSW tuning: the three parameters that control the recall/speed trade-off

-- Index build parameters (set once at CREATE INDEX):
-- m: number of bi-directional links per node (default 16, range 2–100)
--    Higher m → better recall, larger index, slower builds
-- ef_construction: candidate pool size during build (default 64, range 4–1000)
--    Higher ef_construction → better recall, slower builds
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);  -- good default for most workloads

-- ef_search: candidate pool at query time (set per-session or per-query)
-- Higher ef_search → better recall, slower queries
SET hnsw.ef_search = 40;   -- ~90-93% recall, fastest
SET hnsw.ef_search = 100;  -- ~97-99% recall, good for most RAG workloads
SET hnsw.ef_search = 200;  -- ~99%+ recall, for recommendation engines

-- Measure actual recall against your dataset:
-- Compare HNSW results to exact KNN (no index) on a sample
SELECT count(*) FROM (
  SELECT id FROM documents ORDER BY embedding <=> $1 LIMIT 10
) hnsw
WHERE id IN (
  SELECT id FROM documents ORDER BY embedding <-> $1 LIMIT 10  -- exact
);
-- Result / 10 = recall at K=10

Related: the pgvector project on GitHub

Performance Benchmarks: What the Numbers Actually Mean

2xlarge, 8 vCPU, 64 GB RAM, shared_buffers at 16 GB) typically delivers p50 latency under 5ms and p99 under 25ms for cosine similarity search across 1 million 1536-dimensional vectors — with the HNSW index fitting in shared_buffers for in-memory traversal. Pinecone delivers similar p50 latency but with lower p99 variance because it scales infrastructure automatically and does not degrade when the index cannot fit in RAM. The practical observation is that vector search is rarely the latency bottleneck in production AI applications.

An OpenAI embedding generation call adds 50–200ms. An LLM generation call adds 500ms–3 seconds. Optimising vector search from 15ms to 8ms is not meaningfully changing the user experience.

Recall is where the HNSW tuning matters most. For RAG pipelines retrieving context for a language model, 90–95% recall is usually acceptable — a missed chunk occasionally degrades response quality but does not break the product. For recommendation engines or e-commerce search where every missed result is a potential missed sale, tuning ef_search toward 99% recall is worth the query time increase.

Throughput is where Pinecone's architecture provides the clearest and most durable advantage. Pinecone was designed to shard horizontally; scaling from 100 to 10,000 queries per second is a configuration change. Scaling pgvector to 10,000 QPS requires read replicas, PgBouncer connection pooling, careful index memory management, and instance sizing — all achievable, but operationally heavier than a Pinecone slider.

-- Measure pgvector HNSW query performance on your actual dataset
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT id, title, embedding <=> $1 AS distance
FROM documents
ORDER BY embedding <=> $1
LIMIT 10;

-- Key things to look for in EXPLAIN output:
-- "Index Scan using documents_embedding_idx" — HNSW index is being used (good)
-- "Buffers: shared hit=NNN" vs "shared read=NNN"
--   All hits = index fully in shared_buffers (fast, consistent latency)
--   High reads = index is partially on disk (slower, variable p99 latency)
-- "Execution Time: X ms" — this is your vector search latency

-- If reads are high, increase shared_buffers (in RDS parameter group)
-- Rule of thumb: shared_buffers should cover the HNSW index size
-- Index size estimate: vectors × dimensions × 4 bytes × ~1.3 (HNSW overhead)
-- 1M vectors × 1536 dims × 4 bytes × 1.3 ≈ 8 GB
-- 5M vectors × 1536 dims × 4 bytes × 1.3 ≈ 40 GB

Cost Comparison: Three Realistic Scenarios

Scenario 1 — Startup RAG application (500,000 vectors, internal knowledge base, team of 8). With pgvector, the cost is near zero if you already run PostgreSQL — a 500K-vector HNSW index at 1536 dimensions requires approximately 4 GB of RAM, well within most existing instance configurations. With Pinecone Serverless at this scale, the direct infrastructure cost is low ($0–$50/month), but the total cost includes engineering time to integrate a separate API, maintain an additional SDK dependency, add Pinecone to your monitoring stack, and include it in your next security review.

Winner: pgvector. Scenario 2 — Growing SaaS product (5 million vectors, customer-facing semantic search). A 5M-vector HNSW index at 1536 dimensions requires approximately 40 GB of RAM for in-memory index traversal.

2xlarge (64 GB RAM, ~$510/month On-Demand, ~$315/month 1-year Reserved). Pinecone at 5M vectors and moderate query volume runs $70–$200/month depending on QPS. The infrastructure costs are comparable — but pgvector keeps everything in one database, one monitoring stack, and one operational runbook.

The deciding factor is whether the team has PostgreSQL expertise. If yes: pgvector. If not: Pinecone's managed API eliminates the need for DBA knowledge.

Winner: usually pgvector. Scenario 3 — Enterprise AI platform (100M+ vectors, high query volume, multiple regions). At 100M vectors × 1536 dimensions, the raw vector data is approximately 615 GB.

A pgvector HNSW index at this scale does not fit in RAM on any practical single instance — queries hit disk and p99 latency becomes inconsistent. pgvectorscale's DiskANN-inspired index addresses this, but the operational complexity grows. Pinecone's distributed architecture handles this scale with no instance sizing decisions.

Winner: Pinecone.

The Hidden Cost Most Comparisons Ignore

Most pgvector vs Pinecone articles focus exclusively on infrastructure pricing. That misses the largest cost for teams under 50 engineers: operational complexity. When you add Pinecone to a stack that already includes PostgreSQL, Redis, and a message queue, you now have another vendor contract to negotiate, another API to authenticate against, another SDK to version-pin in your CI/CD pipeline, another dashboard to check during incidents, another monitoring integration to configure and maintain, another item in your SOC 2 or ISO 27001 security review, another failure mode when Pinecone's API has an outage, and another line item with a pricing model that requires tracking as your vector count and query volume grow.

For a 10-person team, this overhead is not abstracted away by Pinecone's managed infrastructure — it is distributed across the engineers who own the integration. They become the people who get paged when vector search is slow, who read the Pinecone changelog before SDK upgrades, and who explain the data flow during customer security questionnaires. ' For most teams operating under 50 million vectors, the honest answer is no — at least until the product has demonstrated that vector search is a core, load-bearing component.

When pgvector Wins: 5 Conditions

pgvector is clearly the right choice under five conditions:

• You already use PostgreSQL: this is the most decisive factor — pgvector is a CREATE EXTENSION statement that adds vector capabilities to infrastructure you already operate, monitor, back up, and understand, so there is no new system to learn

• Your vector count is under 10 million: the HNSW index at this scale fits in RAM on a well-sized RDS instance, and query latency at p99 is competitive with dedicated solutions

• You need hybrid SQL and vector search: pgvector's architectural advantage that no dedicated vector database can match without extra round-trips — filtering semantic search by user_id, document_type, subscription tier, date range, or any relational attribute is a single SQL query in pgvector, while in Pinecone relational filtering requires either metadata filters (limited expressiveness, not a JOIN) or multiple API round-trips between Pinecone and your relational database

• You are building an MVP: shipping with pgvector takes an afternoon — adding vector search to your existing PostgreSQL schema, building the HNSW index, and writing the similarity query takes a few hours, not a sprint, and optimising for hypothetical future scale before product-market fit is expensive premature architecture

• Cost matters: keeping embeddings in PostgreSQL eliminates an entire vendor billing relationship — at startup scale, that is a real number

-- pgvector's architectural moat: hybrid SQL + vector search in one query
-- This is impossible in Pinecone without multiple API round-trips

-- Example: find semantically similar documents for a specific user,
-- filtered by their subscription tier and document type
SELECT
  d.id,
  d.title,
  d.created_at,
  d.embedding <=> $1 AS distance
FROM documents d
JOIN user_subscriptions us ON us.user_id = $2
WHERE
  d.owner_id = $2
  AND d.document_type = ANY(us.allowed_types)
  AND d.created_at > NOW() - INTERVAL '90 days'
  AND d.is_published = true
ORDER BY d.embedding <=> $1
LIMIT 20;

-- With Pinecone, the equivalent requires:
-- 1. Query Pinecone with metadata filter (limited to flat key-value, no JOINs)
-- 2. Re-fetch filtered IDs from PostgreSQL to verify subscription access
-- 3. Application-level re-ranking
-- More latency, more code, more consistency risk between data stores

Related: our AWS RDS performance tuning guide

When Pinecone Wins: 4 Conditions

Pinecone is the right call under four conditions:

• Your vector dataset exceeds 50–100 million vectors: at this scale, fitting the HNSW index in PostgreSQL shared_buffers requires instance classes that become expensive, and instance sizing is a recurring operational decision as the dataset grows — Pinecone's horizontal sharding eliminates that decision (pgvectorscale from Timescale is the intermediate option if you need pgvector at this scale, adding a streaming DiskANN-style index that handles 100M+ vectors without requiring full in-memory index residence)

• Vector search is the core of your product: for companies where semantic search is the primary value driver — an AI-native vertical search engine, a document intelligence platform, a consumer recommendation engine — the operational guarantees and performance isolation of a purpose-built system justify the cost and complexity premium, since a bug in the vector search path is a P1 incident, unlike a SaaS product where vector search is one feature among twenty

• You have no PostgreSQL infrastructure and no PostgreSQL expertise: the choice is not pgvector vs Pinecone — it is PostgreSQL with pgvector vs Pinecone API; if you are building greenfield with no DBA knowledge on the team, Pinecone's API-only model is lower-friction than learning PostgreSQL administration alongside building a product

• You need multi-region vector search with contractual SLA guarantees: Pinecone's multi-region deployment is a configuration option, while multi-region PostgreSQL with vector search requires Aurora Global Database or manual replication setup — achievable, but operationally significant

The Start-with-pgvector Strategy: Ship Fast, Migrate if Needed

For most teams facing this decision in 2026, the pragmatic choice is to start with pgvector and migrate to Pinecone if and when the workload demands it. This strategy works for two reasons. The migration path is well-defined: your application retrieves embeddings from PostgreSQL via SELECT ...

ORDER BY embedding <=> $1 LIMIT k. Swapping that to a Pinecone query() call requires updating one function in your data access layer. The embeddings are portable — you generated them with the same model and can upsert them to Pinecone in a batch job.

The switch can happen in a day. The second reason: many teams spend years operating comfortably on pgvector before hitting meaningful scale constraints. A company growing from 0 to 5 million vectors over two years gets two years of zero additional infrastructure overhead, zero additional vendor relationships, and zero additional operational complexity — before the migration question even becomes relevant.

The important caveat: if your application's vector search is deeply integrated with SQL joins (user-scoped retrieval, permission filtering, relational ranking signals), migrating to Pinecone is not a one-function change. It requires redesigning the retrieval architecture, because Pinecone cannot do those joins. In that case, staying on pgvector at larger scale — with pgvectorscale's DiskANN index for RAM efficiency — is often the better path than migrating to a system that requires application-layer workarounds for the relational filtering you rely on.

-- Exporting embeddings from pgvector to Pinecone when migration becomes necessary

-- Step 1: Export all vectors with their IDs and metadata
COPY (
  SELECT
    id::text AS vector_id,
    title,
    created_at::text,
    document_type,
    -- Convert PostgreSQL vector to comma-separated string for export
    array_to_string(ARRAY(SELECT unnest(embedding::float[])), ',') AS embedding_values
  FROM documents
  WHERE is_active = true
) TO '/tmp/vectors_export.csv' WITH CSV HEADER;

-- Step 2: Python batch upsert to Pinecone (process in batches of 100)
# from pinecone import Pinecone
# import pandas as pd
#
# pc = Pinecone(api_key="your-api-key")
# index = pc.Index("documents-index")
#
# df = pd.read_csv('/tmp/vectors_export.csv')
# batch_size = 100
# for i in range(0, len(df), batch_size):
#     batch = df.iloc[i:i+batch_size]
#     vectors = [(row.vector_id,
#                 [float(x) for x in row.embedding_values.split(',')],
#                 {"title": row.title, "type": row.document_type})
#                for _, row in batch.iterrows()]
#     index.upsert(vectors=vectors)
#     print(f"Upserted {i + len(batch)} / {len(df)} vectors")

Related: our database engineering service