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 runs Postgres and needs transactional consistency with joins to relational data, which pgvector provides as ordinary SQL. Every other option copies catalogue attributes into a second store, and the team then owns the synchronisation, which is where freshness bugs start. The trade-off with pgvector is that HNSW index builds slow down and need tuning once a table runs to millions of rows, and 300,000 chunks sits well below that. Amazon Kendra is not a candidate here: it entered maintenance mode on 30 June 2026 and closed to new customers on 30 July 2026, so a new build cannot use it.
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 ordinary WHERE clauses, transactional consistency, and joins to relational data. Aurora has carried pgvector since 0.5.0 added HNSW indexing, and 0.8.0 is available on recent minor versions. The trade-off is that HNSW builds on millions of rows are slow and need tuning.
Why? The discriminator is whether the data already sits in Postgres, rather than raw vector speed.