At what scale does 'just put it in Postgres with pgvector' stop being the right answer?

**Correct: option A.** pgvector is the right choice when three things are true: (1) Postgres is already in your stack, (2) the corpus is under ~10M vectors, and (3) you want transactional consistency between vectors and relational data. **Why these three.** - *Postgres already running.* The operational win of pgvector is that you don't add a new system. One fewer database to monitor, secure, back up, and credential-manage. If you weren't running Postgres, the math changes; standing up Postgres just for pgvector is rarely the right move. - *Sub-10M vectors.* HNSW in pgvector handles this scale comfortably with sub-50ms p99 on commodity hardware. Past ~50M on a single Postgres instance you start running into shared-buffer pressure and WAL overhead. - *Transactional consistency.* You can JOIN vector results with relational tables in a single transaction. No dual-write problem, no eventual consistency between vector store and metadata store. This is pgvector's killer feature for B2B SaaS where 'is this document in this tenant's allowed list' must be enforced atomically with the vector query. **Why the other options are wrong.** - *B (prototypes only).* This is the 2022 take. By 2026, pgvector serves millions of vectors in production at many SaaS companies. Dismissing it for any production load above 100k is uninformed. - *C (billion vectors on default Postgres).* HNSW does scale logarithmically per query, but the whole index has to fit in RAM, and a billion 1536-dim vectors is 6+ TB. Default-tuned Postgres can't handle that. - *D (faster than every dedicated DB).* Postgres adds overhead (MVCC, WAL, shared buffers, transaction isolation) that dedicated vector DBs skip. pgvector is competitive at sub-10M, not universally faster.

**Correct answer: A.** pgvector occupies a real, defensible niche in the 2026 vector-DB landscape. The answer is not 'use Pinecone for everything' nor 'pgvector forever' but a clean set of conditions under which each is right. **The pgvector sweet spot.** 1. *Postgres is already running.* pgvector's primary value is operational simplicity: one database, one backup strategy, one set of credentials. Adding a dedicated vector DB is a real ops tax (security review, monitoring, runbook, on-call). If Postgres is in the stack, pgvector is the lowest-friction path to vector search. 2. *Corpus under ~10M vectors (or up to ~50M with HNSW on big hardware).* pgvector with HNSW handles this comfortably. Beyond that the WAL pressure, shared-buffer competition with normal Postgres queries, and lack of multi-node sharding start to bite. 3. *Transactional consistency with relational data.* You can run a vector search and a JOIN against relational tables in the same SELECT, and you can write to both inside the same transaction. No dual-write problem, no consistency drift between the vector store and the rest of your data. **Why the crossover lands around 10-50M.** - HNSW must hold the graph and the full vectors RAM-resident. 10M float32 1536-dim vectors are ~60 GB; with graph overhead ~80 GB. That fits a single 128 GB Postgres node alongside other workloads. - Past 50M, you'd need 300+ GB of RAM dedicated to the vector index, which competes with Postgres' shared_buffers for normal SQL workloads. - Postgres' single-writer architecture means scaling beyond one box requires sharding at the application layer (Citus or hand-rolled). Dedicated vector DBs ship this natively. - WAL pressure from continuous vector inserts (each insert touches the HNSW graph) becomes a real bottleneck at high write rates. **Why the distractors are wrong.** - *B.* The 'prototypes only' framing is two years out of date.