AIPostgreSQLBackend

Vector Databases for RAG in 2026: pgvector, Pinecone, or Something Else

After building RAG pipelines on 4 production apps with three different vector stores, here is the framework I use to decide between pgvector, Pinecone, and the new wave of dedicated vector DBs.

Hassan Javed

April 2026

10 min read

The RAG choice that matters

When you build a RAG (retrieval-augmented generation) pipeline, half a dozen tools live in the stack — embeddings model, chunker, vector store, retriever, reranker, LLM. The vector store is the one most teams overthink and underdecide on.

After shipping four production RAG apps in the last year, the framework I now use is simple. Most teams should start with pgvector and move only if they hit a specific limit.

Why pgvector is the default

Postgres with the pgvector extension is good enough for 90 percent of RAG workloads in 2026.

What it gives you:

▸Same database as your app — no new ops, no new sync layer

▸Joins with your existing tables (filter vector search by user, by tenant, by date)

▸Transactional consistency

▸One backup, one connection pool, one team owns it

▸pgvector now supports HNSW indexes (added 2024) — fast enough for most apps

What it lacks:

▸Built-in dimensionality reduction or quantization

▸Some advanced query patterns (max marginal relevance, multi-vector)

▸Sub-50ms latency at very large scale (10 million plus vectors)

For typical app workloads — under 1 million vectors, queries under 100ms — pgvector wins on operational simplicity by a wide margin.

When to pick a dedicated vector DB

Specific signals that you have outgrown pgvector:

1.Vectors over 10 million — pgvector's HNSW indexes get expensive in RAM here

2.Sub-50ms p99 latency requirement — dedicated DBs are tuned for this

3.Multi-tenant scale with strict isolation — namespaces in Pinecone simplify this

4.You need built-in reranking, hybrid search, or metadata filtering at scale — pgvector forces you to write it

If none of these apply, pgvector is the right call.

The dedicated options in 2026

Pinecone

The mature default. Easy to set up, scales well, integrates with every framework. Costs more than self-hosted but you do not operate it.

Pick when: B2B SaaS at scale, want managed, willing to pay 70 dollars per month at the entry tier.

Qdrant

Open source, self-host or managed. Beautiful API, fast, well-documented. My recommendation if you want to self-host without Postgres overhead.

Pick when: You want vector search as a service but cannot or do not want to pay Pinecone prices.

Weaviate

Older, more feature-rich, includes built-in reranking and hybrid search. Heavier to operate.

Pick when: You need advanced features out of the box and have ops capacity.

Chroma

The newest, most fashionable. Great DX for prototypes. I have not yet seen it in serious production.

Pick when: Prototyping or building local-first apps.

Turbopuffer

Newer (2024). Object storage backed, claims very low cost at massive scale. Interesting if your workload is read-heavy and cost-sensitive.

Pick when: You have very large vector counts (50 million plus) and cost matters more than latency.

LanceDB

Open source, file-based, good for embedded use cases. Different mental model — vectors live alongside your data in a Parquet-like format.

Pick when: Local-first or notebook-heavy workflows.

My pick per project

After 4 production RAG apps:

▸Project 1 — internal knowledge base for a 50-person company. 200K chunks. pgvector. No regrets.

▸Project 2 — customer-facing chatbot for SaaS. 2 million chunks, multi-tenant. pgvector initially, would migrate to Pinecone if we hit scale.

▸Project 3 — semantic search across 8 million product descriptions. Pinecone from day one. pgvector would have worked but the Pinecone metadata filtering was cleaner for the product taxonomy.

▸Project 4 — RAG over legal documents, strict latency requirements. Qdrant self-hosted. pgvector latency was borderline; dedicated DB gave us headroom.

Pattern: most projects start on pgvector and either stay there or move to Pinecone or Qdrant if they hit a specific limit.

The pgvector setup that just works

For most apps, here is the minimal viable RAG with pgvector:

1.Postgres 16 with pgvector extension enabled

2.A chunks table with id, content (text), embedding (vector(1536)), metadata (jsonb), tenantId (text)

3.HNSW index on the embedding column using vector_cosine_ops

4.OpenAI text-embedding-3-small for embeddings (cheap, good enough for most use cases)

5.Cosine similarity query with metadata filtering — filter by tenantId, order by cosine distance, limit 10

That is the whole vector layer. Five lines of schema and one query.

Embedding model choice

OpenAI's text-embedding-3-small is the right default. 1536 dimensions, cheap, good quality. Use text-embedding-3-large only when you have specifically measured a recall improvement.

Alternatives:

▸Cohere embed-v3 — good for multilingual, marginally better quality for English

▸Voyage embeddings — best quality I have benchmarked for specific domains (code, legal)

▸Local models (BGE, E5) — only when you have a reason to keep data local

For 95 percent of RAG, start with OpenAI text-embedding-3-small.

Chunking strategy matters more than the DB

The vector store is the last thing to optimize in a RAG pipeline. Chunk size, overlap, and chunking strategy matter way more.

Defaults I use:

▸Chunk size: 500 tokens (about 350 words)

▸Overlap: 50 tokens (1-2 sentences)

▸Strategy: semantic chunking by paragraph or section, not naive character splitting

If your retrieval is bad, fix chunking before swapping vector DBs.

Reranking

After retrieving top 20 chunks by vector similarity, rerank them with a cross-encoder before sending to the LLM. This is the single highest-quality improvement in any RAG pipeline.

Default: Cohere's rerank-3 model. Cheap, easy API call, dramatically improves retrieval quality. Worth the extra 200ms per query.

TL;DR

▸pgvector is the right default for most RAG apps in 2026

▸Switch to Pinecone or Qdrant only with a specific reason (scale, latency, multi-tenant)

▸OpenAI text-embedding-3-small is the right embedding default

▸Chunking matters more than DB choice

▸Always rerank after vector search

If you are building a RAG pipeline and want a senior to architect it, contact me. AI and RAG work is part of my service offering.

Drizzle ORM in Production: Patterns I Use After 6 Client Projects

Real Drizzle patterns from shipping it on 6 production apps in the last year — schema design, type safety, migrations, query patterns, and where Drizzle still falls short of Prisma.

10 min readRead

PostgreSQLMongoDB

PostgreSQL vs MongoDB for SaaS in 2026: When to Pick Which

After shipping SaaS apps on both Postgres and MongoDB, here's the decision tree I actually use — schema flexibility, JSONB, indexing, costs, and migration pain.