Cost Estimates vs. Timed Canaries: How to Gate AI-Generated SQL Before Production

A real incident involving an analytics agent that generated a plausible but costly SQL query against a 40-million-row table has sparked debate among database engineers about the best way to vet agent-generated SQL before promotion. The query passed staging and static review but caused excessive heap scans in production, exposing a gap that neither linting nor unit tests could catch. Two schools of thought have emerged: one favors using PostgreSQL cost estimates via EXPLAIN as a fast, lock-free filter in CI pipelines, while the other argues that timed canary runs against representative data are necessary because cost units do not reliably reflect real-world latency or data skew. Cost-based gates are seen as practical for high-frequency OLTP screening, but critics note that stale planner statistics can cause the planner to underprice a dangerous scan. The core question for teams deploying SQL-generating agents is which signal — estimated cost or measured wall time — should have veto power, and at what point the cost of collecting that signal becomes prohibitive.