Postgres vector database or dedicated? The pgvector call for a Next.js RAG app (2026)

Every few weeks a RAG project lands in the ShipGarden gallery with the same unanswered line in its README: where do the embeddings actually live? The reflex answer in 2026 is to bolt on a dedicated vector database. The quieter answer, and often the correct one, is that the Postgres you already run can be your vector database. PostgreSQL plus the pgvector extension turns your existing database into a vector store with one CREATE EXTENSION line, and for most Next.js RAG apps that is where the vectors should stay until the app earns something more specialized.

We curate starters for a living, so the test here is not "which engine wins a benchmark." It is "which one you should clone on day one, and what has to be true before you graduate off it." That reframes the whole decision away from raw throughput and toward the operational shape of your app.

Quick answer (August 2026)

For a Next.js RAG app in 2026, start with a Postgres vector database: pgvector (v0.8.6) gives you HNSW indexing, SQL metadata filtering, and ACID storage inside the database you already back up, and it comfortably handles up to roughly a million vectors. Reach for a dedicated vector database (Qdrant, Weaviate, Chroma, or Pinecone) when you cross roughly 1 to 10 million vectors, need fast pre-filtered metadata search, want native hybrid or multi-vector retrieval, or need horizontal scale a single Postgres node cannot give you. Add pgvectorscale before you add a second database: its StreamingDiskANN index keeps Postgres competitive well past the point most teams assume they must switch. And remember that in most apps the vector store is not the bottleneck, so pick the one whose operations you can live with, not the one with the shiniest chart.

What "a Postgres vector database" actually means

pgvector is a PostgreSQL extension (PostgreSQL License, roughly 22k GitHub stars as of August 2026) that adds vector types and approximate-nearest-neighbor search to the database you already run. You get two index methods, HNSW and IVFFlat, and distance operators for cosine (<=>), L2 (<->), inner product (<#>), L1 (<+>), plus Hamming and Jaccard for binary vectors. Standard vectors index up to 2,000 dimensions; halfvec half-precision vectors reach 4,000, and binary quantization handles far more. Version 0.8 added iterative index scans, which re-scan more of the index when a WHERE filter prunes too many results, one of the older pgvector foot-guns closed.

The point that changes the architecture is not any single feature. It is that the embeddings sit in the same table as your relational rows:

CREATE EXTENSION vector;

CREATE TABLE chunks (
  id          bigserial PRIMARY KEY,
  document_id bigint REFERENCES documents(id),
  content     text,
  embedding   vector(1536)
);

CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);

Retrieval is then just SQL, filters and joins included:

SELECT content
FROM chunks
WHERE document_id = ANY($1)         -- your metadata filter
ORDER BY embedding <=> $2           -- cosine similarity to the query embedding
LIMIT 8;

One connection pool. One backup. One place to reason about permissions. That is the real pgvector pitch, and no dedicated engine can match it if Postgres is already your system of record.

The honest default: for most Next.js RAG apps, pgvector is enough

Here is the curator take the vendor blogs tend to bury: for the typical Next.js RAG app, the vector database is rarely your bottleneck. Most of these apps index thousands to low-millions of chunks, and at that scale a warm HNSW index in Postgres returns in single-digit to low-tens of milliseconds. What actually decides whether the answer is good is chunking, embedding quality, retrieval strategy, and the LLM call, not the microseconds your ANN lookup shaves off.

A January 2026 benchmark that pitted Qdrant against pgvector on a 5,500-document corpus landed exactly here: near-identical latency, with the conclusion that "the bottleneck isn't the vector store." Practitioners on r/Rag say the quiet part out loud too, warning that a separate vector DB means "you will need 2 DBs, and this is a lot of engineering hours to get right." Every embedding you write now has to be written twice, kept in sync, backed up twice, and reconciled when they drift. That is the tax you are actually weighing, and for a small team it is often larger than any query-speed gain.

When Postgres stops being your best vector database

The clean part of this decision is that even Qdrant, a dedicated vendor, publishes an honest list of when pgvector is the right call. Their pgvector trade-offs post (March 2026) names six conditions where staying on Postgres is correct: you have under about a million vectors, you do not need metadata filtering during search, embeddings are tightly coupled to relational rows, you have no hybrid-search requirement, Postgres is already central to your business logic, and your team is small enough to keep the SQL search path simple.

Fail two or three of those and the picture changes. The signals to watch:

• Scale. pgvector is comfortable under ~1M vectors; the community ceiling before pain (index-build time, memory pressure, recall drift under load) sits around ~10M on a single node.
• Filtering. pgvector post-filters metadata, applying your WHERE clause after the ANN step, which adds overhead for tenant-, user-, or category-scoped search. Qdrant's filterable HNSW keeps the filter inside the graph traversal.
• Hybrid and sparse. Postgres tsvector full-text search is not the same as probabilistic BM25. If you need real hybrid dense-plus-sparse retrieval or ColBERT-style multi-vector, that is a dedicated-engine feature today.
• Vector explosion. Token-level (multi-vector) embeddings can turn a 100k-document corpus into tens of millions of vectors, which drags the scale threshold forward fast.

pgvectorscale moved the goalposts (2025 to 2026)

Before you treat "Postgres can't scale for vectors" as fact, note that the phrase is a 2023 claim. That year, a widely cited 1M-vector benchmark found pgvector trailing Qdrant by roughly 15x on throughput. Then pgvectorscale arrived, a Rust extension that adds a StreamingDiskANN index and Statistical Binary Quantization on top of pgvector.

TigerData's April 2025 benchmark on 50 million 768-dimension Cohere embeddings reported Postgres with pgvectorscale hitting 471 queries per second against Qdrant's 41 at 99% recall (an 11.4x edge in their test), and a 4.4x edge at 90% recall. It was not a clean sweep: Qdrant held a tighter latency tail (p99 ~39ms vs ~75ms) and built its index far faster (~3.3 hours vs ~11.1 hours). It is a vendor benchmark and reads like one, so weigh it accordingly. The durable takeaway is not the exact multiplier; it is that adding one extension keeps Postgres in the race at tens of millions of vectors, which is a different world than the 2023 story most roundups still repeat.

How the options compare

Scroll to see more

Option	Where vectors live	Metadata filtering	Hybrid / sparse	Practical scale (single node)	Ops overhead	Managed option
Postgres + pgvector	Same table as your data	SQL WHERE (post-filter)	tsvector, not true BM25	~1M comfortable	None new if you run Postgres	Supabase, Neon, RDS
+ pgvectorscale	Same table as your data	SQL WHERE (post-filter)	Same as pgvector	Tens of millions	Low (one extension)	TigerData Cloud
Qdrant	Separate Rust service	Filterable HNSW (pre-filter)	Native BM25 + multivector	Very high, horizontal	Second DB to run + sync	Qdrant Cloud
Weaviate	Separate server	Built-in, module-driven	Built-in hybrid search	High	Higher memory + ops	Weaviate Cloud
Chroma	Embedded or server	Basic metadata filters	Limited	Small to medium	Near-zero for prototypes	Chroma Cloud
Pinecone	Fully managed (SaaS)	Namespaces + filters	Hybrid supported	Very high, zero-ops	None (you pay instead)	Managed only

The starters worth cloning (a curator's shortlist)

The gallery lens turns this into three clone-and-go paths rather than an abstract tier list.

Stay on Postgres. If you already deploy on Supabase or Neon, pgvector is one migration away, and a Next.js RAG route with the Vercel AI SDK plus Drizzle or Prisma keeps the whole retrieval path in TypeScript against a single database. This is the default we reach for, and it lines up with the RAG-store trade-offs we walked through in the LlamaIndex.TS RAG starter review.

Go dedicated when the signals fire. Once you have decided you genuinely need a separate engine, the choice between the self-hostable three is its own call, and we made it side by side in Qdrant vs Weaviate vs Chroma. Short version: Qdrant for lean production with strong filtering, Weaviate when you want hybrid search and modules handed to you, Chroma for the fastest embedded prototype.

Prototype with zero infra. Chroma runs in-process, so a weekend RAG demo needs no extra service at all; you migrate to Postgres or Qdrant when the demo becomes a product. Where each backend sits relative to the rest of a starter stack is mapped in our open-source Next.js starter scorecard.

A decision framework for your Next.js RAG app

Walk it top to bottom and stop at the first line that fits:

1. Under ~1M vectors, simple filters, already on Postgres. Use pgvector and stop here.
2. Approaching 1M to 10M, or you see index-build or memory pressure on your Postgres box. Add pgvectorscale before you add a second database.
3. You need fast pre-filtered search per tenant, user, or category at scale. Move to Qdrant for its filterable HNSW.
4. You need true hybrid dense-plus-sparse retrieval or ColBERT multi-vector. Qdrant or Weaviate.
5. You want zero-ops and will pay for it. Pinecone, or a managed Qdrant / Weaviate cloud.
6. Pure local prototype, no infrastructure. Chroma embedded, then graduate later.

The curator's call: choose the store whose failure mode you can operate, not the one that wins a benchmark you will never reproduce. For most teams shipping a Next.js RAG app in 2026, that is the Postgres you already run, right up until the day the app proves it needs more.