Most code review checklists are written for application code, and they miss what actually breaks in SQL. A migration that locks a live table during peak traffic. A new foreign key with no index behind it. A WHERE clause built by concatenating a string instead of binding a parameter. None of that shows up in a typical "readable variable names, no duplicated logic" review — SQL has its own failure modes, and the blast radius when one hits production is usually bigger than a bad application deploy.
Some of this is already solved by tooling. A formatter or linter catches inconsistent keyword casing, comma placement, and misspelled keywords before a human opens the diff — that's deterministic and doesn't need a second opinion. What's left for the reviewer is judgment: does this index actually need to exist, is this migration safe to run while the old application code is still deployed, can this dynamic query be exploited, and if the migration goes wrong, how do you get back. That's the review this checklist covers.
Below is the reasoning and runnable examples behind the items that trip teams up most — missing indexes, non-backward-compatible migrations, transaction safety, N+1 patterns, and unparameterized SQL — followed by a numbered checklist you can paste into a pull request template today.
What should SQL review catch that a linter can't?
A formatter can tell you that a keyword is lowercase when your team's convention is uppercase, or that COUTN should be COUNT. It can't tell you that a migration will lock a 40-million-row table for four minutes, or that a new query will start doing a sequential scan once the table grows past its current size. Keep those two review types separate: run formatting and typo checks in CI before a human ever looks at the diff, and spend the human review budget entirely on the judgment calls below.
If your team is still debating tabs vs. spaces or SELECT vs. select in pull request comments, that's a sign the mechanical checks aren't automated yet — see our guide to SQL formatting best practices and the case for uppercase vs. lowercase keywords. Fix that first; it's a bigger time save than anything else on this list, and it stops typo-class bugs like the ones covered in our rundown of common SQL keyword typos from reaching review at all.