When I started ReclamaAI, Pinecone was the obvious default for vector search. It was documented, serverless, had a generous free tier. A year later, with real embeddings and queries in production, I considered migrating to pgvector to unify under Postgres. I did the comparison, almost migrated, and ended up staying with Pinecone. Here's why.
What ReclamaAI needs
Before comparing tools, the real use case:
- Tens of thousands of vectors stored (chunks of laws, jurisprudence, and templates).
- Hundreds of queries per day, one per generation.
- P95 latency target: under 200ms to not slow down the user flow.
- Standard 1536-dimensional embeddings from OpenAI.
- Each query returns the top-5 most similar vectors with metadata filtering by document type.
Not absurd scale. Perfectly operable from either option.
Pinecone, what it gives me
Pinecone is a vector-specialized database. What I appreciate:
- Very low latency. In my case, with no tuning, Pinecone stays comfortably under my target. It's optimized for this and it shows.
- No management. No indexes to maintain, no reindex to run, no HNSW tuning to learn.
- Simple API. Three methods: upsert, query, delete. That's all I use. The official Node library is decent.
- Native metadata filtering. Every vector has metadata (norm type, year, jurisdiction), and filters apply before the search. The feature I use most.
What I don't like:
- It's an external service. Another dependency, another bill, another place that can go down.
- Cost at scale. The free plan covers me for 100k vectors and unlimited queries. The next tier starts at $70/mo. For my current scale, free is fine. For 10x the size, it's real money.
pgvector, what it would give me
pgvector is a Postgres extension that adds a vector type and similarity operators. What I'd gain:
- One database. My vectors would live next to my documents, users, jobs. Real joins between vectors and relational rows without ETL.
- Zero additional cost. My Neon Postgres is already paid, adding pgvector costs nothing more.
- Unified backups and migrations. When I dump the DB, vectors are included. When I rollback schema, vectors rollback with everything.
- Native SQL. Complex filters, joins, aggregations. All of Postgres applied to vectors.
What I'd lose:
- Latency. In my test with reasonably configured HNSW, P95 came in almost at my target limit. If I grow, it goes over.
- Index management. HNSW requires parameters (m, ef_construction, ef_search). Defaults work but aren't optimal. Tuning is dev time.
- Postgres memory. The HNSW index lives in RAM to be fast. At scales of tens of thousands of 1536-dimensional vectors, we're talking about hundreds of MB. My instance has room, but not infinitely.
The real experiment
I migrated the vectors to pgvector in a test branch for a week and ran the same queries against both databases. The latency difference was consistent: Pinecone responded in roughly half the P95 time of pgvector, with an even larger margin at P99.
The difference matters but isn't brutal. For my case, pgvector sits right at the edge of the latency target. For cases where latency matters more (search-as-you-type, real-time recommendations), Pinecone wins comfortably.
The decision: I stayed with Pinecone
Three reasons, in order of weight:
- Latency with headroom. Pinecone gives me margin to grow without tuning. pgvector is already near the limit. Migrating to gain nothing operational and lose margin doesn't convince me.
- My head's time. Maintaining an optimal HNSW index in Postgres is recurring work. Pinecone is "set and forget". As a solo founder, I'd rather pay $70/mo (when it comes) than spend 4 hours a month optimizing indexes.
- Low risk of migrating later. If Pinecone raises prices absurdly or changes its model, migrating to pgvector takes me 3-4 days with the current code. The exit option exists and is cheap. That gives me peace to stay with the comfortable option today.
When I would pick pgvector
If you were starting from scratch today, my recommendation would change by case:
- pgvector if: you already have Postgres, your scale is modest (<100k vectors), you don't need latency <100ms, you value having everything in one DB, and your team is comfortable with SQL.
- Pinecone if: your scale will grow fast, you need ultra-low latency, you don't want to manage indexes, and you prefer paying for a specialized service rather than learning to tune pgvector.
There's no right answer. There's a trade-off between operational simplicity (Pinecone) and unified control (pgvector). For ReclamaAI, today, operational simplicity wins. Tomorrow it could change.