Every time someone starts building a RAG pipeline, the same question will come up: do I need a “real” vector database like Pinecone, or can I just use pgvector with the Postgres I already have?

I can imagine teams agonizing over this decision for weeks. So maybe this will save you some time?

The Case for Staying Put

If you already have a PostgreSQL instance in your stack, adding pgvector is almost always the right first move.

You manage one stateful service instead of two. Your existing backup strategy, monitoring, and security all stay the same. Your vector embeddings live next to your metadata, so you get ACID compliance and standard SQL joins. No syncing between two data stores. No eventual consistency headaches.

Performance? From what I found, for datasets under a few million vectors, pgvector with HNSW indexes is fast. Really fast. It satisfies the latency requirements of most applications without breaking a sweat.

And you’re not paying for another SaaS subscription…

When Pinecone Actually Makes Sense

Pinecone is a purpose-built vector database designed for high-dimensional data at massive scale. It’s serverless and fully managed.

If you’re dealing with hundreds of millions or billions of vectors, a specialized engine handles memory and disk I/O for similarity searches more efficiently than Postgres can. Pinecone also gives you native namespace support, metadata filtering optimized for vector search, and live index updates that are faster than re-indexing a large Postgres table.

Those are real advantages. At a certain scale.

The Decision Is Simpler Than You Think

Stay with Postgres + pgvector if:

• You want to minimize infra sprawl and moving parts
• Your vector dataset is under 5 to 10 million records
• You rely on relational joins between vectors and other business data
• You have existing observability and DBA expertise for Postgres

Consider Pinecone if:

• Your Postgres instance needs massive, expensive vertical scaling just to keep the vector index in memory
• You don’t want to tune HNSW parameters, mmap settings, or vacuuming schedules for large vector tables
• You need sub-millisecond similarity search at a scale where Postgres starts to struggle

That is what I would use to make that decision.

Most teams are probably nowhere near the scale where Pinecone becomes necessary. They have a few hundred thousand vectors, maybe a million or two. Postgres handles that without flinching. Adding a separate managed vector database at that point is just adding operational complexity for no measurable benefit.

The trap is thinking you need to “plan ahead” for scale you don’t have yet. You can always migrate later if you actually hit the ceiling. Moving from pgvector to Pinecone is a well-documented path. But moving from two services back to one because you overengineered your stack? That’s a conversation nobody wants to have.

Start with what you have. Add complexity when the numbers force you to, not when a vendor’s marketing page makes you nervous.

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].