2026-07-14 · 5 min read · Rahul Chitturi
- sql
- database
- review
A production SQL change can look harmless in one long line while hiding a changed join, an extra filter, or a parameter that no longer matches the application payload. Formatting the query before review makes the behavioral change visible before it reaches a migration, dashboard, or release branch.
Treat formatting as part of the review process, not as cleanup after approval. Reviewers should be able to scan joins, predicates, grouping, ordering, and limits without mentally parsing minified SQL.
Normalize the query first
Before discussing indexes or execution plans, make the query structure consistent. A stable format reduces noise when comparing the old and new versions, especially when ORMs generate SQL with changing whitespace or alias names.
- Put each join and major predicate on its own line
- Use consistent alias names for the same tables across examples
- Keep bound parameter names or placeholder positions visible
- Separate formatting-only changes from behavioral query changes
Review parameters with the SQL
Many query bugs live outside the SQL text. The application may send a string instead of a number, an empty array for an IN clause, or a timestamp in the wrong timezone. Pair the formatted query with a sanitized JSON example of the bound parameters.
When an index is proposed as the fix, compare the failing query, expected cardinality, and filter order before editing schema. A formatting pass often reveals that the query changed shape and the index is only treating the symptom.
A Flashman workflow
Use the SQL formatter to make the query reviewable, the JSON formatter for sanitized parameters or API payloads, and the diff tool to compare the release candidate against the last known-good query.
Keep customer data out of shared examples. Replace literals with placeholders that preserve type, length, and selectivity where those details affect debugging.