Structured permit fields must remain the system of record while also feeding RAG. Which data-service choice fits?
Select an answer to reveal the explanation.
Short Explanation
PostgreSQL is the official permit ledger; Cosmos is the flexible AI notebook—pick the ledger for structured truth and the notebook when document/vector shapes fit better, not two bosses arguing.
Full Explanation
Structured permit fields that remain the system of record while also feeding RAG should keep those relational fields in Azure Database for PostgreSQL and use Cosmos DB where flexible document or vector-centric AI patterns fit better. That split preserves constraints, joins, and transactional integrity for permits while allowing document/vector shapes where they excel. Using only Cosmos DB for every relational permit join and abandoning PostgreSQL constraints forces relational workloads into a document model ill-suited as the sole SOR for structured municipal permits. Storing permit system-of-record fields exclusively in Redis with no durable database makes eviction and restart events into data-loss events. Duplicating conflicting systems of record in both stores without a clear ownership rule produces divergent permit truths and reconciliation debt. Exam caveat: polyglot persistence is acceptable when ownership is explicit; the exam rewards PostgreSQL as SOR for structured permits with Cosmos for AI-centric documents/vectors. Operationally, declare PostgreSQL authoritative for permit fields, sync or project into Cosmos/embeddings as derived data, and reject dual-write designs without a single write owner.