pgvector or a dedicated vector database for 20M embeddings?
Simplicity ↔ Search performance
Context
Store and search 20M document-chunk embeddings with tenant filters.
Our RAG product stores document chunks for ~600 tenants. We're at 3M embeddings and expect 20M within a year.
Today it's pgvector with an HNSW index on the same RDS instance as everything else. Queries always filter by tenant and by document ACLs.
A dedicated vector DB promises better recall and latency at scale. pgvector means one database, one backup, and ACLs enforced by the same SQL that guards everything else.
Where does pgvector actually fall over?
Constraints
- Vectors
- 20M × 1,024 dims
- Latency
- p95 < 100 ms
- Filters
- Per tenant + ACLs
- Existing
- Postgres on RDS
pgvector (Postgres)vsDedicated vector DB
Community verdict
10 engineers · 4 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
Simplicity →
Trade-offs
Dimensions
- Simplicity
- 5pgvector (Postgres) scores 5 of 52Dedicated vector DB scores 2 of 5
- Recall at scale
- 3pgvector (Postgres) scores 3 of 55Dedicated vector DB scores 5 of 5
- Filtering
- 5
Community discussion
4 comments
Have you made this decision in production? Share your reasoning.
Sign in to comment20M × 1,024 floats is ~80 GB before index overhead. That fits on one large instance. I would not add a new database until the numbers say I must.
Filtered search is where people get bitten, and pgvector is better at it than its reputation. Partition by tenant (or use partial indexes for big tenants) and the HNSW index only searches what that tenant can see.
Keep the ACL check in the same SQL query. Two systems means two places to forget it.
Our breaking point was index builds: rebuilding HNSW on 15M vectors took hours and starved the primary of memory. We moved vectors to a read replica first, then to a dedicated store when re-embedding with a new model became a monthly event.
Read replica for vectors is a great middle step. Same tooling, isolated blast radius.