pgvector is my default for embeddings because the vectors live with the business data. One query can join, filter by tenant and permissions, mix keyword and semantic search, and answer in milliseconds.
Use it when
- Product or document search inside an app, a support chatbot over a client's knowledge base, 'similar items', duplicate detection.
- Results must be filtered by permissions, client, status or dates with SQL joins and row-level security.
- Keyword and semantic search together (hybrid).
- Answers in milliseconds (about 3–9 ms).
- Up to a few million vectors.
Don't use it when
- Tens of millions of vectors queried rarely: the index must fit in RAM (10M vectors ≈ 77 GB). Use S3 Vectors.
Pricing
Mostly the storage on a Postgres you already pay for: about $5 a month for 1M vectors on an existing Neon database.
Gotchas, with fixes
Gotcha: The HNSW index has to fit in memory, so large collections force a big, always-on database.
Fix: Keep the hot data in pgvector and move the archive to S3 Vectors. Watch Neon's Lakebase Search, which keeps the index on disk.
Instead, consider
- Amazon S3 Vectors Huge, cold or per-client collections.
Worked examples
Where it fits
- An AI chat or LLM feature: Pick 03.
If the answers need your data (RAG).
- Semantic search and RAG: Pick 01.
When a user is waiting and results depend on your data and permissions.
Sources
Last reviewed by Nicolas Dao