pgvector vs Pinecone in 2026: Costs, Scale Limits and Which Vector Database to Pick

Your retrieval demo answered twelve questions perfectly in a notebook, so you shipped it. Six weeks later the corpus is 2 million chunks, the search that returned in 40 milliseconds now takes four seconds, and the CREATE INDEX you kicked off on Friday is still running on Monday. That is when most teams start reading comparison posts, and it is the wrong moment: you have already chosen, and you are looking for permission. Decide it now instead.

pgvector vs Pinecone: the short answer

Pick pgvector if your product's data already lives in PostgreSQL and your embedding count will stay under a few million for the next year. You will spend nothing extra on licences, your vector search and your business filters run in one query, and a single backup covers both. Pick Pinecone if you have no Postgres to attach to, if your corpus is tens of millions of vectors, or if nobody on the team wants to own index tuning.

That is a choice about who operates the index, not about which one finds better neighbours. Both use HNSW-family approximate nearest neighbour search. At a million vectors with sensible settings, neither will be the reason your answers are wrong. Your chunking strategy and your reranker will be.

Here is the honest caveat, and it cuts against the cheaper option. pgvector is an extension, not a product. Nobody is on call for it. When an index build stalls at 38% and the log says the graph no longer fits in memory, that is your Sunday, and the fix requires knowing what maintenance_work_mem does. If your team has no Postgres depth, the $50 a month you save is not actually saved.

Also read: Retrieval Augmented Generation Explained in 2026 for the pipeline this index sits inside.

What each one actually is

pgvector: a type and two index methods, inside your database

pgvector adds vector column types and approximate search indexes to PostgreSQL. You run CREATE EXTENSION vector;, add a vector(1536) column, build an HNSW index, and query with the <=> cosine distance operator. It is a one-click extension on Supabase, Neon, Amazon RDS and Azure Database for PostgreSQL, so "self-hosted" rarely means racking anything.

Version 0.8.0, released in November 2024, added the feature that made it viable for real products: iterative index scans. Before it, a query that filtered by tenant or date applied the filter after the index scan and could hand back three results when you asked for ten. With hnsw.iterative_scan set, the index keeps fetching candidates until your filter is satisfied, up to hnsw.max_scan_tuples. If you evaluated pgvector before late 2024 and dismissed it over filtering, you evaluated a different product.

The storage story is the other half. A vector(n) column costs 4n + 8 bytes. The halfvec type halves that at 16-bit precision with very little recall loss and indexes up to 4,000 dimensions, and binary quantization indexes up to 64,000 dimensions. pgvector's own documentation gives the arithmetic: at 1024 dimensions, a full vector is 4,104 bytes and a bit vector is 136 bytes.

Pinecone: a managed index you never see

Pinecone is a hosted vector database with no servers or index parameters exposed to you. You create an index, upsert records, and query. Storage, replication and the ANN structure are the vendor's problem. Its serverless model meters three things: storage per GB, write units and read units, and since mid-2026 it also bills egress at $0.10 per GB with 100 GB included on paid tiers.

Pinecone also bundles pieces of the pipeline that pgvector leaves to you. The Starter tier includes 5 million embedding tokens a month through Pinecone Inference and 500 reranking requests, so a prototype runs end to end without a separate embedding provider. For a solo builder testing an idea over a weekend, that matters more than any latency chart.

Building this retrieval layer properly, from chunking through reranking to evaluation, is the spine of 360DT's AI Engineer course, where the RAG module is built live against a real corpus rather than a toy dataset.

pgvector vs Pinecone on cost: what you actually pay in 2026

Published unit prices are easy to find and easy to misread, because the two products meter different things. Pinecone charges for storage, reads and writes. pgvector charges you nothing and then quietly charges you for RAM, because an HNSW index wants to live in memory.

Run the arithmetic on a concrete corpus. Two million chunks at 1536 dimensions is 2,000,000 x 6,152 bytes, about 12.3 GB of raw vectors before the index. On Pinecone's published storage rate that is roughly $4 a month of storage, so your bill is set by the $50 Standard floor and your query volume, not by the data. On pgvector, that 12 GB wants to sit in RAM alongside your ordinary working set, which usually means the next instance size up. Neither is free. They are simply billed by different people.

The 12-criteria comparison table

Read this for the rows where the two genuinely differ. Half of a vector database comparison is noise, because both products do cosine similarity over an HNSW graph and both return good neighbours.

Two rows deserve more than a cell. Transactional consistency is the one nobody costs correctly: when a user deletes a document, a Postgres row and a Pinecone vector are two writes that can disagree, and the disagreement surfaces as your chatbot quoting a deleted contract. Region choice is the one Indian teams hit first, because a Starter index pinned to us-east-1 adds a round trip of roughly 200 milliseconds from Mumbai before your model has generated a single token.

Where pgvector breaks, and where Pinecone bites

Here is what usually goes wrong, told the way a colleague would tell you over a desk. You load 4 million rows, run CREATE INDEX, and nothing happens for hours. The default maintenance_work_mem is 64 MB. Your graph needs gigabytes. Postgres has silently dropped to a disk-based build path that community write-ups put at 10 to 50 times slower, and the notice in your log saying the graph no longer fits in memory scrolled past two hours ago. Set maintenance_work_mem before the build, not after, and build the index after the bulk load rather than before it.

The second one is quieter. Your index builds fine, queries are fast for a week, then the table grows and the index no longer fits in shared buffers. Every graph hop becomes a disk read. Nothing errors. Latency just goes from 8 milliseconds to 2 seconds and stays there. This is why the honest pgvector ceiling is a memory number, not a row count.

Pinecone's equivalent surprises are commercial rather than technical. Read units are consumed by the amount scanned, so a broad filter over a large namespace costs more than a narrow one, and a chatty agent that retrieves on every turn can multiply your read volume without anyone noticing until the invoice. The egress line added in mid-2026 catches teams who pull vectors back out in bulk for evaluation runs.

Whoever owns this index also owns its monitoring: recall regression after a reindex, p95 latency, and the cost per thousand queries. That operational half is what the MLOps Engineer course drills, since the AI-300 objectives cover deploying and monitoring these systems rather than building them once.

Qdrant vs pgvector, and the other options worth a look

Qdrant is the option most teams should price before committing to Pinecone. Its cloud free tier is a permanent single-node cluster with 0.5 vCPU, 1 GB RAM and 4 GB disk, with no card required, and it exposes payload filtering and quantization directly. The catch is the one in the pitfalls box: free clusters suspend after a week of inactivity and are deleted after four.

When Qdrant beats both

Choose Qdrant when you need dedicated vector-engine behaviour but want to control where it runs, including inside your own VPC in ap-south-1 for data residency reasons. That is a common requirement in Indian financial services, where the retrieval index is treated as customer data. Running it yourself is a container and a volume, which is a cloud engineering task rather than a database one, and sits squarely in what an AWS Solutions Architect and DevOps track covers.

The option people forget

Under about 50,000 chunks you may not need a vector database at all. An in-process index rebuilt on deploy, or Azure AI Search if you are already on Azure, will serve a support-documentation bot perfectly well; those vector features sit in the AI-103 Generative AI Developer path. The smallest thing that works is the right answer more often than the interesting thing.

Also read: How to Build Production RAG for why the index is rarely the reason a demo fails in production.

A worked scenario, and one team that published its decision

Take a two-person data team at a mid-size Indian general insurer. They have 400,000 policy documents, chunked to about 1.8 million embeddings at 1536 dimensions, roughly 11 GB of raw vectors. Their claims application already runs on Azure Database for PostgreSQL. Queries are bursty: a few hundred an hour during office time, near zero overnight. Compliance wants everything in an Indian region.

pgvector wins this decisively, and not on price. It wins because the residency requirement is satisfied by a database already approved, because "which policies can this user see" is an existing SQL predicate rather than a metadata schema to redesign, and because two people cannot afford a second system with its own access model and its own outages. Their real cost is one instance-size upgrade and a Saturday spent learning what hnsw.ef_search does. If that same team had 30 million chunks and a dedicated platform engineer, the answer would flip.

That is an illustrative scenario, not a customer of ours. For a published one, the team at Confident AI wrote up their move in a post titled "Why we replaced Pinecone with pgvector", and consultancies report 40 to 60 percent cost reductions on medium-scale workloads after consolidating vectors into an existing managed Postgres. Treat those percentages as directional: they depend entirely on how much RAM the receiving instance already had spare.

The pipeline that keeps this index fresh, incremental loads, deduplication and change capture, is data engineering rather than AI work, which is why teams pair a retrieval build with a live Microsoft Fabric data engineering program when the source documents keep moving.

Choose pgvector if, choose Pinecone if

Choose pgvector if

• Your application's records already live in PostgreSQL and your retrieval filters are the same predicates as your application's permissions.
• You expect fewer than about 5 million vectors within the next year, or you are willing to use halfvec and reranking to push that further.
• Data residency, VPC isolation or audit scope makes a second vendor expensive in paperwork rather than rupees.
• Someone on the team can read a query plan and is not frightened by a GUC.

Choose Pinecone if

• You have no Postgres to attach to, or your source of truth is a document store, a warehouse or object storage.
• Your corpus is already in the tens of millions of vectors, or growing fast enough that you will cross that line before you can replatform.
• You are one or two people shipping a product and every hour spent on index tuning is an hour not spent on the product.
• You want embeddings and reranking from the same vendor rather than wiring three services together for a prototype.

One popular piece of advice is worth arguing with: "start on the managed service, migrate later if it gets expensive." That reads sensibly and usually costs more than it saves, because the filter logic you write against a metadata API is the part you have to throw away, and you will not throw it away while the feature is shipping. Start where you intend to end up.

The verdict

For the majority of readers of this page, which is to say engineers in India building a retrieval feature inside an application that already has a relational database, pgvector is the right choice and Pinecone is the expensive convenience. The trade-off you are accepting is explicit: you own the index. You will spend a weekend learning HNSW parameters, you will hit the memory wall once, and you will fix it. In exchange you keep one system, one security review and one backup, and your vector search participates in the same transaction as the rest of your data.

Pinecone is the right answer for a narrower group, and it is a genuinely good product for them: small teams with no database to attach to, corpora in the tens of millions, and anyone whose time is worth more than the line item. Nothing about that is a compromise. It is a different constraint.

What would change that recommendation is scale you can see coming. If your roadmap says 50 million chunks by next June, do not start on pgvector and plan to migrate. Industry write-ups in 2026 suggest most new AI engineer postings name RAG and vector database experience explicitly, while the number of engineers who can point at a retrieval system they actually operated stays small. Being able to defend this choice in specifics is the part that survives an interview.

Related guides

• SQL Query Optimization in 2026 because the same EXPLAIN ANALYZE habits that fix slow joins are what you will use on a slow vector scan.
• How Do Large Language Models Work? for what an embedding actually is before you decide where to store a few million of them.
• LLM Evaluation in 2026 to prove a retrieval change improved answers instead of hoping it did.
• 8 Generative AI Project Ideas for 2026 if you want a portfolio project that exercises this decision properly.
• AI Engineer Jobs in Bangalore 2026 for which employers are naming this stack in their listings and what they pay for it.

Frequently asked questions

Stop reading and build one. Index a corpus you care about in Postgres, measure recall and p95 latency, then do the same on a free Pinecone Starter index and compare your own numbers. That is the sequence the AI Engineer course runs live over 16 weeks; if you would rather compare paths first, the full certifications overview and a free demo class cost nothing. In your position, we would spend the weekend on pgvector and keep the $50.

About this guide. 360 Digital Transformation is an Authorized Training Partner of Anthropic and Microsoft. Other certification bodies, vendors and employers named here are not affiliated with us. Product features and pricing change often; figures cited were checked on 21 September 2026.