A county must choose a vector store for a mid-scale permitting FAQ assistant and has strong relational-database skills but limited search-platform operations experience. Which selection rationale is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Pick the wrench your crew already knows how to use. If the county lives in Aurora day-to-day, pgvector can carry a mid-scale FAQ without forcing a brand-new search ops practice overnight.
Full Explanation
Vector-store selection for a mid-scale county permitting FAQ should weigh operational familiarity against feature depth. When the team already runs relational databases well and scale is moderate, Aurora PostgreSQL with pgvector is an appropriate choice: it keeps embeddings next to skills and tooling staff already operate, reduces the need for a new search-platform practice, and can meet FAQ retrieval needs without OpenSearch-level ops. The rationale is fit-for-skills and fit-for-scale, not “one AWS service stores all text.”
Requiring OpenSearch Serverless solely because it is supposedly the only AWS service that can store text fails factually and conceptually—many stores hold text, and the stem’s constraint is ops familiarity, not maximum search features. Rejecting stores and retraining a foundation model whenever an FAQ changes fails because FAQ drift is a retrieval/content update problem, not a continual retrain loop. Storing FAQ embeddings only in each resident’s browser localStorage fails on durability, consistency, privacy, and shared municipal corpus requirements.
Exam caveat: AIP-C01 often tests choosing the operationally sustainable option under stated skill and scale constraints, not the flashiest search product by default.
Operational check: benchmark FAQ recall on Aurora/pgvector at expected QPS, document backup/restore for the embedding tables, set a scale trigger for revisiting OpenSearch later, and confirm FAQ updates re-embed without model retraining.