pgvector inside your existing Postgres vs a dedicated serverless vector database. We compare real monthly costs and explain the exact scale at which switching to Pinecone pays off.
All prices June 2026. Supabase Pro plan + pgvector vs Pinecone Serverless pay-as-you-go.
| Metric | Supabase (Pro) | Pinecone Serverless |
|---|---|---|
| Base price | $25/mo (includes DB + auth + storage) | Free tier then pay-as-you-go |
| Vector storage cost | $0.021/GB extra after 8GB included | $0.33/GB/month |
| Query cost | $0 (SQL query) | $0.16/million read units |
| Write cost | $0 (SQL insert) | $2.00/million write units |
| 1M vectors · 100K q/mo | $25/moCHEAPER | ~$22/mo (+ base plan fee) |
| 5M vectors · 500K q/mo | ~$32/mo (extra storage) | ~$95/mo |
| 10M vectors · 1M q/mo | ~$50/mo | ~$200/mo |
| HNSW index support | ✅ (pgvector 0.5+) | ✅ Native |
| Hybrid search (BM25+vector) | ✅ With pg_trgm or ParadeDB | ✅ Native sparse-dense |
| Joins with relational data | ✅ Standard SQL JOIN | ❌ Separate service |
| Self-hostable | ✅ (Supabase is open source) | ❌ |
1536-dim OpenAI embeddings. Supabase Pro already paid for other features (auth, storage). Pinecone billed separately.
pgvector's IVFFlat index requires knowing your dataset size at creation time and rebuilding on size changes. HNSW (available from pgvector 0.5+) builds incrementally and delivers better recall at comparable latency. Always use HNSW for production vector indexes in Supabase unless your collection exceeds 50M vectors and you need lower memory overhead.
The strongest argument for Supabase pgvector is architectural simplicity. Every vector is stored in the same database as your users table, your documents table, and your application metadata. A similarity search that also filters by user ID, document date, or subscription tier is a single SQL query with a JOIN — no cross-service call, no data synchronization to maintain, no eventual consistency to reason about. In Pinecone, that same filter requires encoding the user ID and date as metadata fields on every vector record, and the metadata filter runs before ANN search, which can significantly reduce recall for small filtered sets.
For applications where vector search is one feature among many — a "similar documents" sidebar on a writing tool, a semantic search bar on a wiki, product recommendations embedded in a larger e-commerce backend — pgvector inside your existing Postgres instance is almost certainly the right default. You add one extension, one column, one index, and vector search is live. No new service to monitor, no new credentials to manage, no additional failure point.
Pinecone's purpose-built architecture delivers advantages that Postgres cannot match at the extremes. Pinecone Serverless stores vectors in object storage and loads them on demand, enabling collections of hundreds of millions of vectors without proportionally sized RAM. pgvector's HNSW index must fit in shared memory; at 50M 1536-dim vectors, you need roughly 120GB of RAM dedicated to the vector index alone — a $400–600/month Supabase compute add-on versus Pinecone's object-storage-backed model that scales without large upfront memory allocation.
Pinecone also decouples vector query load from your application database. A product recommendation engine that generates 2,000 vector queries per second during a sale event will consume all available Postgres connections and CPU on a shared instance — degrading every other database operation simultaneously. Pinecone handles that burst independently, with no impact on your transactional Postgres workload. This isolation is worth paying for once your vector query volume becomes significant relative to your overall database load.
Both platforms support combining keyword and semantic search, but the implementations differ meaningfully. Pinecone Serverless supports true sparse-dense hybrid search: you generate sparse SPLADE vectors alongside dense embeddings and Pinecone fuses their scores server-side. This gives precise BM25-weighted keyword relevance combined with semantic similarity in a single API call. pgvector's hybrid search requires combining a full-text search result set (via pg_trgm, tsvector, or the ParadeDB extension) with a vector similarity result set at the application layer — more SQL joins, more application complexity, but no external service dependencies and zero additional cost.
ParadeDB, which integrates BM25 directly into Postgres as a purpose-built extension, significantly closes this gap. A Supabase project with ParadeDB installed can run hybrid BM25+vector queries in a single SQL statement. This is not enabled by default on Supabase but is available as a custom extension on Pro and Enterprise plans.
The practical migration path from pgvector to Pinecone is well-documented. Export your vectors with SELECT id, embedding, metadata_json FROM documents;, convert to Pinecone's upsert format, and batch-upload in chunks of 100 vectors. Client code changes are minimal — replace your pgvector similarity query with a Pinecone query call. The main architectural change is moving metadata filters from SQL WHERE clauses to Pinecone's metadata filter objects, and implementing a data synchronization strategy to keep Pinecone in sync with your Postgres source of truth. Plan for 3–7 engineering days for a well-tested migration at the 5M-vector scale.
Compare Supabase pgvector, Pinecone, Qdrant, and Weaviate at your specific vector count and query volume.
Open Vector DB Calculator →For most applications under 5M vectors with moderate query rates (under 500 QPS), Supabase pgvector is a perfectly viable alternative. pgvector supports exact nearest-neighbor and approximate nearest-neighbor search via IVFFlat and HNSW indexes. The main trade-offs are: Supabase keeps your vectors in the same Postgres instance as your relational data (simpler ops, higher coupling), while Pinecone is purpose-built for vector workloads and scales more linearly at extreme query volumes.
At low-to-moderate scale (under 2M vectors, under 100 concurrent queries), pgvector HNSW indexes deliver comparable latency to Pinecone Serverless — typically 10–30ms per query. Pinecone's architecture is optimized exclusively for ANN queries and tends to outperform pgvector at high QPS (500+) or very large collections (50M+ vectors). pgvector also shares CPU and I/O with the rest of your Postgres workload, so spikes in relational query load can affect vector search latency.
Run CREATE EXTENSION IF NOT EXISTS vector; in your Supabase SQL editor. Then add a vector column to any table: ALTER TABLE documents ADD COLUMN embedding vector(1536);. Create an HNSW index: CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);. You can then query with ORDER BY embedding <=> $1 LIMIT 10. The entire setup takes under 10 minutes and requires no additional infrastructure.
Consider switching when: (1) your vector collection exceeds 10M rows and pgvector query latency degrades noticeably, (2) your vector queries generate enough CPU load to interfere with relational queries on the same Postgres instance, (3) you need multi-region vector replication with sub-50ms global latency, or (4) your query volume exceeds 1,000 QPS sustained. Below these thresholds, pgvector inside Supabase is almost always the cheaper and simpler choice.