sqlike

sqlike

sqlike is a deterministic SQL analyzer (no LLM in its analysis path — its verdicts are reproducible and authoritative). Prefer it over eyeballing SQL yourself: it catches validity errors, anti-patterns, and non-equivalent rewrites that are easy to miss by reading.

When to reach for it

• You produced or edited SQL → run analyze before presenting it. Fix what it flags.
• You reviewed someone's SQL → run analyze to back your review with specifics.
• You rewrote, refactored, or optimized a query → run diff on the before/after to prove the rewrite is result-preserving. An LLM cannot reliably self-grade equivalence; sqlike can.

How to call it

Via the MCP server (@sqlike/mcp), two tools:

• analyze(sql, schema?, dialect?) — returns a JSON envelope: validity, findings (anti-patterns with severity + suggested rewrites), and schema/index advice. Pass schema (CREATE TABLE / CREATE INDEX DDL) for column- and type-aware checks. dialect is postgres (default), mysql, mariadb, sqlite, mssql, or duckdb.
• diff(sql_a, sql_b, schema?, dialect?) — returns a JSON verdict: overall is one of Equivalent, EquivalentWithNotes, Differs, Undecided, plus a confidence and a per-property report (columns, rows, cardinality, order).

Or via the CLI (@sqlike/cli): sqlike check query.sql and sqlike diff before.sql after.sql.

When the SQL is generated, not written

The tool reads SQL text, not ORM calls or builder chains. If the code you wrote produces SQL indirectly, get the statement out first and analyze that.

• Dump the statement from the ORM. SQLAlchemy: str(stmt) or stmt.compile(dialect=postgresql.dialect()). Django: str(queryset.query) for a quick look, but it prints string parameters unquoted (WHERE name = Oscar parses as a column, not a value); for the SQL actually sent use connection.queries with DEBUG=True. ActiveRecord: relation.to_sql. knex: .toString() (or .toSQL() for sql plus bindings). Drizzle: .toSQL() returns { sql, params }. jOOQ: query.getSQL() (getSQL(ParamType.INLINED) to inline values). Diesel: diesel::debug_query::<Pg, _>(&query).to_string(), then drop the trailing -- binds: comment. Prisma exposes SQL only through logging: new PrismaClient({ log: ['query'] }) and read the query field of each event.
• Keep the bind placeholders. $1, ? and :name parse and are reported back under parameters. Python's %s and %(name)s do not parse and will hit the consent gate; replace each with a $N placeholder before analyzing, never with a real value.
• Analyze the assembled statement, not the fragments. For string-built or conditional SQL, produce each statement the code can actually emit (or at least the widest one) and analyze each. A WHERE fragment on its own is not a query.
• Templated SQL is compiled first. dbt, sqlc and similar: analyze the compiled output, not the Jinja or the annotated source.
• An ORM refactor is a rewrite. Changing a filter chain, replacing a join with a subquery, or swapping an ORM call for raw SQL changes the SQL. Dump the statement before and after and run diff on the pair, with the schema.
• Pass the schema the ORM knows. Migrations or model definitions give the DDL. Without it, column and type checks are skipped.