SQL ReviewLinted. Reviewed. Approved.
Catch bad SQL before it ships. Linting catches typos. Semantic rules catch anti-patterns. Approval workflows catch policy violations.
SQL review architecture
Three layers. One review.
Linting
Syntax and style. Catches typos, formatting violations, and dialect mistakes before the SQL ever reaches the database.
Semantic rules
Schema-aware checks. Require primary keys, prohibit destructive cascades, enforce naming conventions, flag missing indexes.
Policy with approval
Role-based human review. Production changes route to a DBA; lower environments auto-approve; break-glass paths leave an audit trail.
SQL review guide
Read in order.
- 01
Why SQL review
When strict requirements help and when they get in the way. The case for review, from devs and DBAs.
- 02
From linting to governance
The three layers — linting, semantic rules, policy with approval — and the main SQL review tools compared.
- 03
SQL review in GitHub
Three integration paths: GitHub Action, GitHub App, GitOps CI. Pick one, ship it.
SQL review for PostgreSQL
PostgreSQL.
A style guide plus three rule deep-dives — the layer-2 semantic checks that catch the most damaging Postgres-specific anti-patterns.
Style guide
An extensive style and review guide for PostgreSQL. Naming, indexing, migration safety.
Read →Require primary key
Every table must declare a primary key. Why the rule matters and how it's enforced.
Read →Prohibit CASCADE
Block ON DELETE CASCADE / ON UPDATE CASCADE. Why cascades are usually wrong and what to do instead.
Read →Enforce NOT VALID in CHECK
Adding a CHECK constraint to a non-empty table without locking it. The Postgres-specific safety pattern.
Read →
SQL review in Bytebase
Reviewed at the gateway.
Bytebase runs all three layers inline. Linting and semantic rules execute on every change — in the SQL Editor, in the change workflow, in CI on pull requests. Policy with approval routes production changes to the right reviewer. Each rule has a configurable severity, scope, and engine target.
One review. Every change.
SQL review questions
Common questions.
- What is SQL review?
- SQL review is the practice of checking SQL — usually schema changes, but also data operations and ad-hoc queries — before it runs against production. Review happens in three layers: linting (syntax and style), semantic rules (schema-aware checks like 'every table needs a primary key'), and policy with approval (a human reviewer plus a workflow that gates the change).
- What's the difference between linting, semantic rules, and review?
- Linting checks the SQL itself — typos, formatting, dialect mistakes. Semantic rules check the SQL against the schema — does it require a primary key, does it use a destructive cascade, does it index foreign keys? Approval review brings a human into the loop — the rule engine flags issues, then a DBA or peer decides whether to merge. All three layers are complementary; mature teams run all three.
- How does SQL review fit into CI/CD?
- SQL review runs as a CI step — typically on pull requests in GitHub or GitLab. Linting and semantic rules run automatically and surface findings as PR comments or status checks. Policy with approval gates the merge: a DBA approval or a passing rule check is required before the SQL can deploy. Tools like Bytebase wire all three layers into the same Git workflow.
Every post in the series.
General principles.
- 01
SQL Review: From Linting to Governance
The three layers of SQL review and the main tools that implement them.
- 02
Three Ways to Integrate Automatic SQL Review into GitHub
GitHub Action, GitHub App, and GitOps CI — the three paths and when to pick which.
- 03
Is SQL Review Necessary? Real Talk From Developers
Working developers and DBAs answer whether strict review and schema conventions actually help.
PostgreSQL.
- 01
PostgreSQL SQL Review and Style Guide
An extensive style and review guide for PostgreSQL — naming, indexing, migration safety.
- 02
Require Primary Key: A SQL Review Rule Explained
Why every table needs a primary key, and how this rule is enforced.
- 03
Prohibit CASCADE: A SQL Review Rule Explained
Why ON DELETE/UPDATE CASCADE is usually a footgun, and what to do instead.
- 04
Enforce NOT VALID in CHECK: A SQL Review Rule Explained
Adding CHECK constraints to large tables in PostgreSQL without locking.