Exam-style
A team already runs its product catalogue and entitlements in Aurora PostgreSQL. Their RAG feature covers 300,000 chunks and every query must filter on department and effective date and join back to live catalogue rows. Which vector store suits them?
Reveal the answer
B. Aurora PostgreSQL with pgvector, keeping vectors beside the relational rows and filtering with ordinary WHERE clauses
The discriminator is that the team already lives in Postgres and needs transactional consistency with joins to relational data, which pgvector gives for free as plain SQL. Every other option means copying catalogue attributes into a second store and owning the synchronisation, which is where freshness bugs come from. The real trade-off with pgvector is that HNSW index builds get slow and fiddly in the millions of rows, and 300,000 is well inside comfortable territory.
Q. When is Aurora PostgreSQL with pgvector the better vector store for RAG?
A. When the team already runs Postgres and wants metadata filtering as plain WHERE clauses, transactional consistency, and joins to relational data. The trade-off is that HNSW index builds on millions of rows are slow and need tuning.
Why? The discriminator is whether you already live in Postgres, not raw vector speed.