pgvector is perfect for Postgres. ManyVector is for what comes next.
pgvector works great up to a scale. When you outgrow it, ManyVector gives you a purpose-built path forward — with billions of vectors, native hybrid search, and none of the Postgres operational baggage.
1B+ vectors
not the 10–50M practical limit of a Postgres instance
<5ms
purpose-built HNSW, not a general database extension
BM25 + RRF
native fusion — no manual SQL joins required
ManyVector vs pgvector, side by side.
Feature
ManyVector
pgvector
Storage model
✓ S3-compatible object storage backend — your bucket
✗ PostgreSQL heap — vectors stored as Postgres rows
Scale ceiling
✓ Billions of vectors, horizontally scalable
✗ ~10–50M vectors on typical hardware; single-instance bound
Vector index
✓ HNSW tuned for ANN — purpose-built
✗ HNSW and IVFFlat — general-purpose extension
Full-text search
✓ Native BM25 full-text search
✗ PostgreSQL tsquery/tsvector — not BM25
Hybrid search (RRF)
✓ BM25 + vector with RRF fusion, built-in
✗ Manual SQL required — no built-in RRF fusion
Namespace branching
✓ Copy-on-write branching for safe index updates
✗ No namespace branching concept
Object storage support
✓ S3, GCS, R2, MinIO natively supported
✗ Tied to Postgres storage — no object storage
Ops model
✓ No VACUUM, no bloat, no connection pool sizing
✗ Postgres ops: VACUUM, table bloat, connection pools
Purpose-built
✓ Designed exclusively for vector search workloads
✗ Extension for a general relational database
When to switch from pgvector to ManyVector.
If you have fewer than 5 million vectors and want everything in one Postgres database, pgvector is probably the right tool. These are the specific signals that it is time to move.
Signal 1
You are crossing 10M vectors.
pgvector starts to show ANN latency degradation past 10M vectors on typical hardware, and scaling past 50M requires significant Postgres infrastructure investment. ManyVector is built from the ground up to handle billions without re-architecting your stack.
Signal 2
You need sub-5ms ANN at scale.
pgvector's HNSW is solid for a general database extension, but it is not tuned for vector search as a primary workload. ManyVector's HNSW implementation is purpose-built — delivering consistent sub-5ms ANN without competing with relational query traffic on the same instance.
Signal 3
You need copy-on-write branching.
When you need to test a new embedding model against your production index without downtime or data duplication, pgvector has no native answer. ManyVector's namespace branching lets you create an instant copy-on-write branch, evaluate, and merge — like git for your vector index.
Common questions
Should I replace Postgres with ManyVector?
No — and you should not try to. Postgres is excellent for relational data: user records, transactions, structured metadata. ManyVector is excellent for vector search workloads. The right architecture is to use both: Postgres for relational data, ManyVector for your vector index. They complement each other. Moving your user table into a vector database would be the wrong call.
Is pgvector good enough if I have under 5M vectors?
Yes, honestly. If your dataset is small, you already run Postgres, and you do not need BM25 hybrid search or namespace branching, pgvector is a sensible choice — one less service to operate. ManyVector becomes the better trade-off once you are pushing past 5–10M vectors, need sub-5ms ANN SLAs, or need retrieval features that pgvector does not have.
Can I run ManyVector alongside my existing Postgres database?
Yes — this is the recommended setup. Your application reads relational data from Postgres and sends vector search queries to ManyVector. The two services operate independently. You can migrate incrementally: start by moving your vector index to ManyVector while keeping all other data in Postgres.
How does ManyVector handle hybrid search differently from pgvector?
With pgvector, hybrid search means writing manual SQL that joins vector similarity results with full-text search results and implements your own ranking logic — it is error-prone and adds significant query complexity. ManyVector runs BM25 full-text search and ANN vector search simultaneously in one query, merges the result sets using Reciprocal Rank Fusion (RRF), and returns a single ranked list. No custom SQL, no manual fusion code.