SQLFluff vs Squawk vs SlowQL: Choosing the Right SQL Static Analyzer for Your Stack

There are three serious open source SQL static analyzers worth knowing about in 2026. Most engineers have heard of SQLFluff. Fewer know Squawk. SlowQL is newer. They solve different problems and the differences matter more than most comparisons let on.

This article breaks down what each tool actually does, where it stops, and which one belongs in your pipeline.

SQLFluff

GitHub

SQLFluff describes itself as "the SQL linter for humans." That's accurate as far as it goes.

SQLFluff is a linter and auto-formatter. Its primary job is enforcing consistent style across your SQL codebase - capitalization, indentation, spacing, aliasing conventions. It supports an impressive range of dialects: ANSI, PostgreSQL, MySQL, BigQuery, Snowflake, Redshift, DuckDB, Spark SQL, T-SQL, and more. It integrates with dbt for templated SQL. It can auto-fix most of what it flags.

Where SQLFluff excels:

• Enforcing consistent SQL style across a team

• dbt projects with Jinja templating

• Pre-commit hooks for formatting

• Teams that want configurable style rules

Where SQLFluff stops:

SQLFluff does not catch security vulnerabilities. It does not flag a DELETE without WHERE, a leading wildcard killing your index, or a hardcoded password in a migration. It is a style tool, not a safety tool. The distinction matters.

If your pipeline only runs SQLFluff, your SQL is consistently formatted right up until it takes down production.

Install:

pip install sqlfluff
sqlfluff lint queries.sql --dialect postgres

Squawk

GitHub

Squawk is a static analysis tool for PostgreSQL SQL files and schema migrations. It is designed to check migrations and SQL scripts during development or in CI pipelines for potentially dangerous operations that could lead to locks, downtime, or compatibility issues.

That's a precise description. Squawk is narrow and deep where SQLFluff is broad and shallow on safety.

Its focus is PostgreSQL migration safety - detecting schema changes that will cause table locks, blocking operations, or unexpected downtime. It warns about things like adding constraints that require a full table scan and block writes, or using 32-bit integer fields that could hit the max integer limit. It integrates directly with GitHub pull requests, posting comments on migration files before they merge.

Where Squawk excels:

• PostgreSQL migration safety

• Detecting lock-causing schema changes

• GitHub PR integration for migration review

• Teams running zero-downtime deployment pipelines

Where Squawk stops:

Squawk is built specifically for PostgreSQL. It does not support MySQL, BigQuery, Redshift, Snowflake, or any other database. It does not catch query performance patterns, security vulnerabilities, compliance issues, or cost problems. If you are not running PostgreSQL or if your concern is query performance rather than migration safety, Squawk is not the right tool.

Install:

pip install squawk-cli
squawk migrations/*.sql

SlowQL

GitHub

SlowQL takes a different approach. Where SQLFluff focuses on style and Squawk focuses on PostgreSQL migration safety, SlowQL focuses on the patterns that cause production incidents across six dimensions: security, performance, reliability, compliance, quality, and cost.

It is database-agnostic, runs completely offline, and is designed to fit into CI pipelines without network calls. SQL never leaves your machine.

171 rules across six dimensions:

Security (45 rules) catches SQL injection vectors, hardcoded credentials, privilege escalation patterns, weak cryptography in queries, and compliance violations including GDPR, HIPAA, PCI-DSS, SOX, and CCPA.

Performance (39 rules) flags leading wildcards that bypass indexes, functions wrapped around indexed columns that break sargability, cartesian joins, correlated subqueries, unbounded operations, and deep offset pagination.

Reliability (19 rules) catches DELETE and UPDATE without WHERE, truncation without transactions, cascade delete risks, missing transaction rollbacks, and deadlock patterns.

Cost (20 rules) targets expensive patterns on cloud data warehouses — SELECT * in ETL pipelines on Athena or BigQuery where you pay per byte scanned, full table scans, redundant indexes, and deep pagination against COUNT queries.

Quality (30 rules) covers code complexity, naming conventions, NULL comparison errors, missing primary keys, and non-deterministic queries.

Compliance (18 rules) maps to specific regulatory requirements - PII selection without audit trails, PHI access patterns, CVV storage violations, and financial data modification without tracking.

Where SlowQL excels:

• Teams that need security and compliance coverage alongside performance

• Multi-database environments (MySQL, PostgreSQL, BigQuery, Redshift, Snowflake, and others)

• Locked-down environments where SQL cannot leave the machine — banks, hospitals, regulated industries

• CI pipelines needing a hard fail on critical severity issues

• dbt models, Airflow DAGs, Flyway and Liquibase migrations, stored procedures

Where SlowQL stops:

SlowQL performs static analysis. It does not execute queries, read your schema, or analyze execution plans. It catches universal patterns - the ones that are dangerous regardless of data distribution or schema specifics. For schema-aware analysis or dialect-specific migration safety in PostgreSQL, Squawk is a better fit.

Install:

pip install slowql
slowql --input-file sql/

Side-by-side comparison

How to choose

Use SQLFluff if your primary concern is consistent SQL style across a team, you use dbt, or you want auto-formatting in pre-commit hooks.

Use Squawk if you run PostgreSQL and your primary concern is migration safety and zero-downtime deployments.

Use SlowQL if you need to catch security vulnerabilities, performance anti-patterns, compliance violations, or cost problems in your SQL before it ships. Especially if you work in a regulated environment or a multi-database stack.

Use more than one. SQLFluff and SlowQL are complementary. SQLFluff keeps your SQL readable and consistent. SlowQL keeps it safe. Running both in CI costs nothing and covers the full range from style to incident prevention.

Running all three in CI

name: SQL Analysis

on: [push, pull_request]

jobs:
  sql-checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - run: pip install sqlfluff slowql squawk-cli

      # Style check
      - run: sqlfluff lint sql/ --dialect postgres

      # Migration safety (PostgreSQL only)
      - run: squawk migrations/*.sql

      # Security, performance, compliance
      - run: slowql --non-interactive --input-file sql/ --fail-on high

The right tool depends on what you are trying to prevent. Style problems, migration downtime, and production incidents are three different concerns that happen to all involve SQL. Treating them as the same problem and solving them with a single tool means leaving coverage gaps in at least two of the three.

The three tools above cover all of it.

Built something with SlowQL? Open an issue or start a discussion on GitHub. Feedback on rule accuracy and false positives is especially useful.