2026-07-08 · 5 min read · Rahul Chitturi
- sql
- incident-response
- database
During a database incident, an unreadable SQL statement can slow every decision. Long joins, copied ORM output, and inline JSON blobs hide whether the query is selecting too much data, missing a predicate, or touching the wrong tenant.
Formatting the query is not cosmetic. It makes the shape of the operation reviewable before someone runs an emergency fix against production.
Separate query shape from values
Pretty-print the SQL first, then list bound parameters beside it. This keeps reviewers from confusing a safe WHERE clause with a value substitution bug, and it reduces the risk of pasting customer data into shared notes.
- Identify SELECT, UPDATE, DELETE, and transaction boundaries explicitly
- Check tenant, account, or environment filters before execution
- Keep parameters redacted but preserve useful types and lengths
- Compare the proposed fix with the last known-good query
Review before and after snapshots
Incident SQL often evolves quickly. Save the original query, the formatted version, and the final command that actually ran. If the query includes JSON conditions or timestamp windows, format those supporting values too so the review does not depend on memory.
A rollback-safe workflow includes expected row counts, a dry-run SELECT when possible, and a clear statement of which indexes or constraints protect the operation.
A Flashman workflow
Use the SQL formatter to make copied queries readable, the diff tool to review changes between drafts, the JSON formatter for embedded payloads, and the timestamp converter for incident windows. Keep production records local and redact identifiers before sharing.
After the incident, store the formatted query with the postmortem so future reviewers can understand the fix without reconstructing a one-line statement from logs.