Python civic services must query Azure Database for PostgreSQL under load for a permitting RAG back end. What is the appropriate approach?
Select an answer to reveal the explanation.
Short Explanation
Let the Python service talk to PostgreSQL the civilized way—with a real client or ORM—so the permitting RAG path stays automated under load instead of someone pasting SQL between chats.
Full Explanation
Python civic services backing a permitting RAG workload should connect to Azure Database for PostgreSQL with a supported PostgreSQL client, SDK, or ORM under load. Proper clients support TLS, connection pooling, parameterized queries, and retries appropriate for Azure-hosted PostgreSQL. That is the standard application-tier approach for municipal AI backends—not interactive or browser-exposed database access.
Shelling into the database VM and pasting SQL by hand for each resident chat turn is not automatable, not scalable, and bypasses application controls. Exposing the PostgreSQL admin port on the public internet without authentication is a critical security failure. Storing connection strings in client-side JavaScript bundled to resident browsers leaks credentials and places the database endpoint in an untrusted tier.
Exam caveat: Azure Database for PostgreSQL is reached from application compute (for example Container Apps or App Service) with managed networking and secrets—not from end-user browsers. Operational check: store the connection string in Key Vault or app settings, enforce TLS, enable pooling in the Python client, run a load test that sustains permitting RAG QPS, and verify no connection strings appear in frontend bundles or logs.