pgvector Reduces Pinecone's Advantage
Charles Chretien, co-founder of Prequel, on the modern data stack’s ROI problem
The real shift is that vector search stopped looking like a standalone database category and started looking like a feature inside the Postgres stack developers already use. Pinecone originally won by giving teams a fast managed way to store embeddings and run similarity search for RAG and semantic search. But once pgvector made vector indexing available inside Postgres, many teams could keep their app data, metadata filters, and vectors in one system instead of adding a separate database.
-
Pinecone’s original value was specialization. It was built as a managed vector database focused on fast retrieval, low latency, and production operations for embeddings. That mattered most when vector search was new and most teams did not want to assemble the stack themselves.
-
pgvector narrowed that gap by bringing HNSW and IVFFlat vector indexes directly into Postgres. In practice this means a developer can store users, documents, metadata, and embeddings in the same database, then run vector search plus normal SQL filters together, which removes a lot of system complexity.
-
That same pattern helps explain why Supabase has momentum. Supabase wraps Postgres with auth, storage, APIs, and AI oriented features, including vector support and newer Vector Buckets, so teams can ship an app backend and basic AI retrieval inside one product instead of stitching together Pinecone plus separate backend services.
Going forward, standalone vector databases will need to win on workloads that vanilla Postgres handles less well, like very large scale retrieval, lower cost at high volume, or multimodal data pipelines. LanceDB is already pushing in that direction by packaging vectors with a broader multimodal lakehouse, which shows where the next layer of differentiation is moving.