How to Choose a Vector Database: Pinecone, Weaviate, pgvector, Milvus in Practice

Six months ago, a cross-border e-commerce client pulled me into an architecture meeting. Their engineering lead was excited: the team had picked Milvus, calling it the industry's strongest option with the most GitHub stars. They'd already built out the cluster. I asked one question: how much data is in your knowledge base right now? Their answer: over forty thousand documents.

Forty thousand. At that scale, pgvector on a mid-range cloud instance would have been sufficient. Instead, they spent three weeks maintaining a distributed system engineered for billions of vectors. The system itself was sound. They'd mistaken a scale they might need someday for a requirement they had today, then paid the cost upfront.

Vector database selection has one principle: choose one that aligns with your current scale, your team's operational capability, and your budget. RAG knowledge systems succeed or fail at the retrieval layer. Model choice matters less than operational stability in production.

Four candidates: understanding each one's nature

Pinecone is a fully managed cloud service. You pay as you go without touching infrastructure. Weaviate is open source with native hybrid search and modular embeddings. You can self-host or use their managed version. Milvus is built for massive scale and distributed high throughput. It's powerful but complex. pgvector is a PostgreSQL extension that puts vector retrieval directly into the relational database you likely already use.

Comparing Milvus and pgvector is comparing a container ship to a delivery truck. The best choice depends on what you're moving and where.

Selection matrix: scale, cost, self-hosting complexity, Chinese language support

This matrix is what we use when evaluating options with clients. The numbers are approximate, not binding.

Vector databases don't understand Chinese. Chinese retrieval quality depends on your embedding model and how you chunk documents. Rather than picking a database for Chinese friendliness, invest effort in choosing an embedding with strong Chinese semantic representation and chunking long documents cleanly. The database stores vectors and computes distances.

Why we usually recommend pgvector first

Start with pgvector if you're working with under ten million vectors, your team already uses PostgreSQL, and you lack a dedicated database operations person. You'll get it right.

Three reasons support this. First, pgvector lives in the same database as your operational data. You can JOIN directly when filtering metadata. You don't reconcile between a separate vector store and your main database. This saves substantial work in regulated environments like financial services or healthcare. Second, operations cost stays near zero. You back up and monitor pgvector the same way you do Postgres. Third, you reserve budget and attention for what shapes the experience: chunking strategy, embeddings, and reranking.

We've seen the reverse. Clients start with a dedicated vector database. Every RAG response is inaccurate. They debug across three systems: the vector store, the main database, the sync pipeline. Troubleshooting costs multiply. They move back to pgvector. The problem surface shrinks.

When should you scale up? Three signals matter: your main table approaches tens of millions of vectors, retrieval latency stays high after tuning HNSW, or you need multi-tenant scaling. At that point, moving to Milvus or Pinecone makes sense. You'll have real traffic data. Your choice will be informed. Starting with pgvector, collecting user behavior, then deciding whether you need heavier infrastructure. This path outpaces betting on a heavy system from the start.

Selection isn't the finish line. Going live is.

RAG systems look smart in demos because you shape the questions. The real test comes after launch, when users ask unexpected things, upload messy PDFs, and notice every error. Picking the right database lays a foundation only. Chunking strategy, reranking, and feedback loops determine whether the system survives.

At Tenten, we almost always start new RAG systems with pgvector. We build the retrieval quality evaluation pipeline first. We discuss heavier databases only when real usage data shows the need. Our engineers stay on-site and track adoption growth. For us, a system your team opens daily is the only one truly live.