A free Postgres extension vs a managed vector database. Cost shape, dimension limits, and who owns the operations.
| pgvector | Pinecone | |
|---|---|---|
| What it is | Open-source Postgres extension (v0.8.x) | Managed serverless vector database |
| Cost model | Free extension; you pay for Postgres | Usage-based: reads, writes, storage |
| Entry cost | $0 self-hosted; managed Postgres from about $25/mo | Free Starter tier; $20/mo Builder; $50/mo minimum Standard |
| Index types | HNSW and IVFFlat, tuned by you | Managed serverless indexes, tuned for you |
| Dimension limits | vector type indexes to 2,000 dims; halfvec to 4,000 | Handles common embedding sizes, including 3072, without a special type |
| Filtering and joins | Full SQL: joins, transactions, exact filters | Metadata filtering within namespaces |
| Scale sweet spot | Up to a few million to tens of millions of vectors per instance, RAM permitting | Built for very large and elastic workloads |
| Ops burden | Yours: index builds, memory, tuning, vacuum | Pinecone's: capacity and tuning are managed |
| Reliability path | Whatever your Postgres setup provides | 99.95% uptime SLA on Enterprise |
| Where it runs | Anywhere Postgres runs: RDS, Supabase, Neon, Cloud SQL, your laptop | Pinecone's cloud (AWS, GCP, Azure regions) |
pgvector itself is free open source under the PostgreSQL license. Your cost is the database it runs in, and the driver is RAM, because an HNSW index performs best when it fits in memory. A managed Postgres like Supabase Pro starts at $25 per month, entry-level RDS instances land in a similar range, and self-hosting costs whatever your server does. The important property is the shape: cost grows in steps when you size up the instance, not per query.
Pinecone bills the opposite way. The Starter tier is free with 2GB of storage and monthly read and write unit allowances, Builder is a flat $20 per month, and Standard starts at a $50 monthly minimum and then meters usage: storage at $0.33 per GB per month, writes at $4 to $4.50 per million write units, and reads at $16 to $18 per million read units depending on cloud region. Enterprise starts at a $500 monthly minimum with higher unit rates and a 99.95 percent uptime SLA.
That difference in shape matters more than the sticker prices. Steady moderate traffic favors pgvector's fixed instance. Spiky or fast-growing query volume favors Pinecone's elasticity, but it also means a traffic spike shows up directly on the bill, so estimate your read units before committing.
Pick pgvector when you already run Postgres and your vectors need to live near your business data. Retrieval in real applications is rarely pure similarity search: it is similarity plus tenant scoping, permissions, date ranges, and joins against customers or documents. In SQL that is one query with transactional guarantees. In a separate vector store it is metadata syncing and glue code you now maintain.
It also keeps the stack boringly simple. One database, one backup story, one connection string, and it works identically on a laptop and in production. For the RAG systems I build for small businesses, corpus sizes are in the thousands to low millions of vectors, and pgvector handles that comfortably on modest hardware.
Two caveats from experience. First, the standard vector type can only be indexed up to 2,000 dimensions, so 3072-dimension embeddings like OpenAI's text-embedding-3-large need the halfvec type or a shortened dimension setting. Second, you own the tuning: HNSW build memory, ef_search, and the iterative index scans added in 0.8.0 that fix recall on heavily filtered queries. None of it is hard, but it is yours.
Pick Pinecone when the index outgrows what one Postgres box comfortably holds, when traffic is unpredictable, or when nobody on the team wants to own database tuning. Serverless means capacity, index management, and recall tuning are Pinecone's problem, and namespaces give you clean multi-tenant isolation without designing it yourself.
The current pricing tiers removed the old objection that Pinecone was expensive to start on. A free tier with 2GB of storage and a $20 Builder plan cover small production apps, which was not true a couple of years ago, and the Enterprise tier with its uptime SLA gives you a compliance and reliability path that a self-managed extension cannot promise.
The caveat is cost predictability at scale. Reads at $16 to $18 per million units are where bills climb, so run your projected query volume through their pricing before you commit, not after the first surprising invoice.
Most pgvector vs Pinecone posts frame this as a performance shootout, but benchmarks age badly here. pgvector's 0.8.x releases fixed the filtered-query recall problem that older benchmark posts lean on, so a 2023 comparison tells you little about the current extension. The durable difference is architectural: whether retrieval needs SQL joins against live business data, and who carries the operational pager.
The dimension limit is the other thing that rarely gets mentioned and bites in week one: pgvector's standard vector type indexes up to 2,000 dimensions, which quietly rules out 3072-dimension embeddings unless you use halfvec or shorten the embedding. Pinecone does not make you think about this. And on the other side, Pinecone's $50 Standard minimum is billed even in a quiet month, while nobody bills you for an idle Postgres extension you already had.
Start with pgvector if you already run Postgres. Most teams I work with never outgrow it, and the ones that do know exactly why: the index no longer fits in RAM at a sane instance price, or nobody wants to keep tuning it. That is the right moment to move to Pinecone, with real usage numbers in hand so the read-unit bill is a calculation instead of a surprise. Starting on Pinecone from day one makes sense mainly when you know the scale is coming or you have no Postgres and no appetite for running one. What I would avoid is adopting a second database for a corpus of fifty thousand vectors.