Audit SQL queries for cost and performance issues

sql-sentinel statically audits SQL for cost and performance patterns that can drive warehouse spending. Its engine separates scripts into statements while honoring quotes and comments, applies 20 rules, and produces a severity-weighted health score from 0 to 100 with an A-F grade. The prioritized plan puts critical findings first and explains why each pattern may be expensive and how it could be changed.

The rule set covers broad column reads, missing filters, leading-wildcard searches, functions on filtered columns, Cartesian joins, DISTINCT, unbounded sorting, the NOT IN NULL trap, implicit casts, and excessive OR conditions. Other checks address COUNT(DISTINCT), unordered limits, scalar subqueries, numerous joins, missing partition filters on likely fact tables, string concatenation, unpartitioned windows, unfiltered writes, SELECT * inside EXISTS or IN, and UNION versus UNION ALL.

Use it when reviewing a SQL pull request, preparing a dashboard query or dbt model for production, investigating a slow query, or conducting a warehouse cost-reduction sweep. It can provide a second review before a query reaches production and help order a FinOps investigation.

Treat findings as candidates for investigation. Expression or trigram indexes, partition pruning, small tables, and intended CROSS JOIN or UNION semantics can alter the verdict. A query on a small table may be inexpensive despite matching a rule. The fact-table check relies on names such as *_events and *_log, so it is advisory.

A health score is not measured savings. Before applying a proposed rewrite, preserve result equivalence, including NULL and duplicate behavior, and examine plans, warehouse dry-run results, and actual billing. EXPLAIN ANALYZE executes queries and requires separate authorization for its data access and cost.

Input is SQL text or a SQL file. The command-line engine accepts a file path; the programmatic interface accepts a SQL string and a dialect option. For example:

const { auditSql } = require('./scripts/sql-sentinel');
const report = auditSql(yourSqlString, { dialect: 'bigquery' });
console.log(report.healthScore);      // 0-100
console.log(report.grade);            // 'A' | 'B' | 'C' | 'D' | 'E' | 'F'
console.log(report.prioritizedPlan);  // array, worst findings first

Severity weights are 25 for critical, 12 for high, 5 for medium, and 1 for low findings. The output orders remediation work; its estimates require validation against the actual execution environment.

The described workflow covers BigQuery, Snowflake, Redshift, Postgres, and Spark SQL. The executable Node engine and rules live in the separate sql-sentinel repository. Choose and review a commit, tag, or release before running that third-party code. Keep private SQL local unless external processing is authorized.

Analytics engineers working with dbt or Looker, data platform teams, SQL reviewers, and teams pursuing warehouse FinOps can use the audit to focus their review effort. The analyzer has zero dependencies and an MIT license.