Postgres + pgvector vs a real vector database

The default architectural decision for any AI-flavoured product in 2026 is between extending Postgres with the pgvector extension and running a specialised vector database alongside it. The answer for the kind of company we build at Moonlabs is, in roughly nineteen out of twenty cases, Postgres. This is also the answer we recommend, almost reflexively, to the founders we incubate.

This essay is the actual reasoning. Including the cases where it stops being true, because the pgvector defaultism gets pushed too far in some quarters and we want to be honest about where it breaks.

The shape of the decision

Most AI-flavoured products end up needing to do something like: find the most semantically similar items to a query. Documents to a question. Past tickets to a new ticket. Products to a description. Knowledge base entries to a user prompt. This is a vector-similarity search problem and the standard infrastructure for it is some flavour of vector database.

In 2022 the choice was mostly between specialised tools — Pinecone, Weaviate, Qdrant, Milvus, Chroma. Each had different operational characteristics. None of them was Postgres. Adopting any of them meant adding another piece of infrastructure to your stack.

In 2023 the pgvector extension matured. By 2025 the index types in pgvector (HNSW specifically) had caught up to specialist offerings on most metrics that early-stage teams actually care about. By 2026 the architectural question shifted: do you need the specialist tool, or does pgvector cover it.

For most teams we work with, the answer is pgvector. Strongly.

Why pgvector wins for the typical early-stage AI product

Reason one: operational simplicity. Adding a specialist vector DB means another service to deploy, monitor, back up, secure, and pay for. Postgres is already in your stack. Adding pgvector is a CREATE EXTENSION vector; and a migration. The operational delta is roughly nothing.

Reason two: transactional consistency. With pgvector, your vectors live in the same database as your application data. You can INSERT INTO items (..., embedding) inside the same transaction that creates the item. The classic specialist-DB failure mode — vector store and primary DB drift apart because one write succeeded and the other failed — does not exist. This is a much bigger deal than it sounds. We have debugged production data drift in three separate companies; it always cost more than running pgvector would have.

Reason three: cost. A specialist vector DB at production scale typically costs £200-£800 a month at the cheapest meaningful tier. pgvector adds essentially nothing to your existing Postgres bill. Over a year that is £2,400-£9,600 saved on operational cost. For an early-stage company with a £400k runway, that money is meaningful.

Reason four: query expressiveness. With pgvector you can write SQL that joins vector similarity with relational filters in a single query. "Find the five most semantically similar items where customer_id = X and created_at > 30 days ago and status = active." Specialist vector DBs do this; they do it more awkwardly. Once you have written ten of these queries you stop wanting to leave Postgres.

Reason five: backup, replication, and recovery. Your DB-level backup and replication already cover the vectors. Point-in-time recovery works. Read replicas work. Your existing DBA muscle works. None of these things are free with a specialist tool — they all have to be relearned, often with worse maturity.

These five reasons compound. Most teams that adopt a specialist vector DB at the early stage do so because the AI ecosystem reflexively recommends it, not because the engineering case actually stacked up. The default should be pgvector. The burden of proof should sit with anyone arguing for the specialist tool.

Where pgvector stops being the right answer

Now the inverse, because the defaultism becomes wrong above certain thresholds.

Threshold one: scale of vectors. pgvector with HNSW indexing performs well up to roughly 10-50 million vectors on commodity Postgres hardware, depending on dimensionality and query patterns. Above that, the index size, build time, and query latency start to suffer. We have hit this twice in our own companies. Both times we eventually moved a specific high-volume index to a specialist tool while keeping the rest in pgvector.

Threshold two: specialised query patterns. If you need filtering with very complex multi-field predicates against vectors, multi-vector search (where each item has multiple embeddings), or specialised approximate-nearest-neighbour variants, the specialist tools have features pgvector does not. Most teams do not need these. If you do, you usually know it.

Threshold three: throughput. pgvector queries are competing for the same connection pool as your application traffic. If you need to run hundreds of vector queries per second per pod, the resource contention with regular query load can become a problem. The fix is usually a read replica dedicated to vector queries, but at some scale a specialist tool gives better operational separation.

Threshold four: hosted-service preference. Some teams genuinely prefer a managed service. Pinecone and friends do offer "managed" in a way that even managed Postgres providers do not quite match for vector workloads specifically. This is a legitimate preference and we will not argue against it for teams whose constraints favour it.

The honest summary: if you cross one of these thresholds, evaluate. If you do not cross them, pgvector remains the right default.

The migration story, in case you guess wrong

A side argument we hear, often from teams that have already paid for a specialist vector DB and want to feel okay about the decision, is "what if we outgrow pgvector and have to migrate?". Two responses.

First, you almost certainly will not. Most early-stage products never get within a factor of ten of the pgvector ceiling.

Second, if you do, the migration is not as bad as the framing suggests. The vectors are already produced by your embedding pipeline; that pipeline does not change. You add a write to the new store, dual-write for a period, switch reads, decommission the pgvector index. The work is real — a few weeks for a senior engineer — but it is bounded and well-understood. Compared with the operational cost of running the specialist tool for a year you did not need it, the migration looks cheap.

We treat the migration as a graduation event in the product, not as a risk to be hedged. Plan to graduate when you actually need to. Until then, do the simple thing.

What we teach in the Academy

The reason we are explicit about this in the Coding pillar of the Academy is that almost every student arrives having watched a YouTube tutorial that defaulted to Pinecone or Weaviate. The reasoning behind the default is rarely articulated. The student has not been told that "the cheapest, fastest, lowest-operational-cost path is almost always pgvector and you should not move off it without a specific reason."

We have all the cohort projects start on Postgres + pgvector unless the student has a real argument for going further. By week four most of them have understood why, and by demo day none of them have wanted to switch. It is, of all the architectural defaults we teach, the one that feels most boring and turns out to be most consequential.

The Moonlabs Academy teaches the operator-grade engineering defaults — Postgres, pgvector, Cursor, Claude Code, evals — in the Coding pillar. Twelve weeks in Derby. Cohort starts 15 June 2026.