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 a metadata filter applies after the HNSW index scan, so a selective filter can return fewer results than asked for until HNSW iterative scans are enabled, which AWS recommends for filtered knowledge bases and which need pgvector 0.8.0 or later. 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.4.1; HNSW indexing came with 0.5.0, and the current minor versions carry 0.8.2. The trade-off is that a metadata filter applies after the HNSW index scan, so a selective filter can return fewer results than asked for until HNSW iterative scans are enabled, which need 0.8.0 or later.
Why? The discriminator is whether the data already sits in Postgres, rather than raw vector speed.