Forem: Makroumi

Real-Time SQL Analysis in VS Code: Catch Dangerous Queries Before You Save the File

Makroumi — Mon, 16 Mar 2026 10:27:47 +0000

Most SQL bugs are caught in one of three places. Code review,
where a tired engineer might miss them. Staging, where the
dataset is too small to reveal the problem. Production, at 2am,
where they cause the most damage.

The SlowQL VS Code extension adds a fourth option: your editor,
before you even save the file.

What it does

SlowQL for VS Code runs 272 static analysis rules against your
SQL as you type. Diagnostics appear in the Problems panel
automatically. Open a .sql file and it works. No database
connection, no configuration, no pipeline to set up first.

The kind of bugs it catches are the ones that look completely
fine until they aren't. A DELETE with no WHERE clause that
wipes your entire customers table. A LIKE pattern starting
with a wildcard that silently bypasses your index on every
single query. A GRANT ALL PRIVILEGES that gives your app user
god mode access to your entire database. A cartesian join
that returns every row times every row because someone forgot
the JOIN condition.

All of it flagged in real time. Before you save. Before you
commit. Before anyone reviews it.

What gets flagged

272 rules across six dimensions:

Security catches SQL injection vectors, hardcoded credentials
in migration files, privilege escalation and dynamic SQL
construction that opens injection surfaces.

Performance catches full table scans, leading wildcards that
bypass indexes, functions on indexed columns, N+1 patterns
and unbounded queries with no LIMIT.

Reliability catches DELETE and UPDATE without WHERE clauses,
missing transactions around multi-statement operations and
data loss risks.

Quality catches NULL comparison errors, implicit joins,
deprecated syntax and naming violations.

Cost catches cloud warehouse antipatterns. SELECT * on wide
tables in BigQuery and Athena, unbounded scans in scheduled
jobs, repeated subqueries that could be materialized.

Compliance catches GDPR violations, HIPAA risks, PCI-DSS
and SOX compliance issues at the query level.

14 dialects, dialect-specific rules

107 of the 272 rules are dialect-aware. Set your dialect
once in VS Code settings and SlowQL fires only the rules
relevant to your database engine. No false positives from
rules that don't apply to your stack.

PostgreSQL, MySQL, SQL Server, Oracle, SQLite, Snowflake,
BigQuery, Redshift, ClickHouse, DuckDB, Presto, Trino,
Spark, Databricks.

Schema-aware validation

Point SlowQL at your DDL files and it validates your queries
against your actual schema. Catches references to tables and
columns that don't exist. Suggests missing indexes on
filtered columns.

This is where static analysis stops being generic and starts
understanding your specific database. A SELECT on a column
that doesn't exist in your schema gets flagged before the
query ever runs.

Why offline matters

Everything runs on your machine. Your SQL never leaves your
editor. No API calls, no telemetry on your query content,
no external service processing your database schema.

This matters more than people realise. Engineers at banks,
healthcare companies and fintech teams often cannot pipe
their SQL to an external service for analysis. The offline
constraint is not a limitation. It is a deliberate design
decision that makes SlowQL usable in environments where
cloud-based tools are not an option.

Three ways to run it

VS Code extension for real-time diagnostics as you write.
Install from the marketplace, open a .sql file, done.

CLI for local analysis and scripting:

pip install slowql
slowql queries.sql

Docker if you don't want to install Python:

docker run --rm -v $(pwd):/src makroumi/slowql /src/queries.sql

GitHub Actions to block dangerous SQL from merging:

- uses: makroumi/slowql-action@v1
  with:
    path: "./sql/**/*.sql"
    fail-on: high

The feedback loop SQL never had

Application code gets linted in the editor, type-checked
at compile time and reviewed by automated tools before it
merges. SQL gets reviewed by a human who is focused on
business logic, not injection surfaces or index bypass
patterns.

The SlowQL VS Code extension closes that gap at the
earliest possible point in the development cycle. The
same query that would have paged you at 2am gets a red
squiggly line at 2pm before you even commit it.

SlowQL is open source. VS Code extension, CLI, Docker
and GitHub Action all available at
github.com/makroumi/slowql

7 SQL patterns that look fine in review and destroy you in production

Makroumi — Fri, 13 Mar 2026 11:03:46 +0000

Originally published at makroumi.hashnode.dev

A teammate pushed a query on a Friday afternoon. No red flags in review.
It had been running fine in staging for weeks.

By 2am Saturday, the on-call engineer was paged. Response times had gone from 50ms to 8s. We didn't recover until Sunday.

One query. One pattern that nobody caught. A weekend gone.

I've catalogued the SQL patterns that cause incidents, not the obscure edge cases, but the ones that pass code review, behave on small datasets, and silently wait for your table to grow past a threshold nobody anticipated.

These are the seven I see most often, with short diagnostics and fixes you can apply in code review, CI, and monitoring.

The leading wildcard

-- This query will never use your index
SELECT * FROM users WHERE email LIKE '%@gmail.com';

Why it fails: A leading wildcard (%...) prevents index seeks; the database must scan the entire table. Works fine on small data, catastrophic at scale.

Fixes:

Use trailing wildcards when possible (LIKE 'gmail%').
Use full-text search for substring/suffix matching.
Store and index a reversed string column if you frequently need suffix matches.
Consider trigram or specialized indexes (pg_trgm in Postgres) for substring searches.

Detection: EXPLAIN shows sequential scan; cardinality estimate equals table size.

A function wrapped around an indexed column

-- Index on created_at is ignored
SELECT * FROM orders WHERE YEAR(created_at) = 2024;

-- Index-friendly version
SELECT * FROM orders
WHERE created_at >= '2024-01-01' AND created_at < '2025-01-01';

Why it fails: Applying a function to a column in WHERE disables sargability, the engine can't use the index for seeks.

Fixes:

-Push computation to the constant side (range predicates).

-Create a functional/indexed expression if you must query that function (functional indexes in Postgres, expression indexes in MySQL 8+).

Avoid repeated function evaluation in hot paths.

Detection: EXPLAIN shows index not used; add an index on the expression if necessary.

SELECT * in production queries

-- Fetches 47 columns when you need 3
SELECT * FROM events WHERE user_id = 123 ORDER BY created_at DESC LIMIT 20;

Why it fails:

Rakes unnecessary bytes across the wire and memory.
Breaks covering/index-only plans.

On columnar warehouses (BigQuery/Redshift/Athena) you pay per byte scanned — SELECT * can become extremely expensive.

Fixes:

Explicitly list columns you need.
Use narrower projections in APIs and services.
For warehouses, test cost on representative data.

Detection: Review changesets for SELECT *; run explain/cost estimation on representative data.

DELETE or UPDATE without WHERE

-- Runs at 3am in a cleanup job
DELETE FROM sessions;

-- What was intended
DELETE FROM sessions WHERE expires_at < NOW();

Why it fails: A missing or accidentally removed WHERE clause can wipe an entire table. This often happens during refactors, copy/paste, or when a developer runs a query interactively and forgets to reapply the filter in application code.

Fixes:

Use explicit transactions and backups for risky maintenance jobs.
Add safety clauses (e.g., LIMIT with repeated runs) or require an explicit flag to run destructive jobs.
Author review checklists and CI/PR checks to catch mass-deletes.
Run destructive jobs from separate, audited service accounts.

Detection: Linting, CI checks that flag DELETE/UPDATE without WHERE, changelogs and deployment gating.

Missing or inefficient pagination

-- OFFSET scans previous rows every time
SELECT * FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 10000;

Why it fails: OFFSET causes the database to scan and discard rows up to the offset. At high offsets this becomes O(offset). Cursor-based or keyset pagination keeps response time stable.

Fixes:

Use keyset pagination (WHERE created_at < last_seen_created_at ORDER BY created_at DESC LIMIT 20).
Use indexed columns for pagination predicates.
For APIs, return opaque cursors instead of numeric offsets.

Detection: Look for OFFSET in queries; test with high offsets on representative data.

JOINs without restrictive predicates (fan-out)

-- Produces massive intermediate results
SELECT u.id, o.id, oi.*
FROM users u
JOIN orders o ON o.user_id = u.id
JOIN order_items oi ON oi.order_id = o.id
WHERE u.region = 'EU';

Why it fails: Missing or weak join/filter conditions cause explosive intermediate result sets. If one side is large, the join multiplies rows and memory/IO usage spikes.

Fixes:

Filter early, push predicates into join drivers.
Ensure join keys are indexed.
Use EXISTS/IN appropriately to avoid duplication when you only need existence.
Denormalize or pre-aggregate in OLAP workloads.

Detection: EXPLAIN shows large row estimates for join stages; monitoring spikes in temporary disk usage.

Implicit type conversions and mismatched types

-- Implicit cast prevents index usage
SELECT * FROM users WHERE id = '123';

Why it fails: Comparing different types often triggers implicit casting; the database may cast the column, not the constant, disabling index use. It also leads to unexpected behavior.

Fixes:

Use consistent types for columns and constants.
Cast constants, not columns (e.g., WHERE id = 123::bigint).
Add strict linting and schema checks in CI.

Detection: EXPLAIN shows index ignored; static analysis/linting can catch literal-type mismatches.

Why these keep shipping

None of these are exotic. Every engineer reading this has probably written at least one of them.

They ship because code review is done by humans under time pressure who are focused on logic and architecture, not query execution plans. They ship because they work perfectly in staging where tables have thousands of rows, not millions. They ship because there's no automated check in the pipeline asking whether a WHERE clause is missing or a wildcard is leading.

The fix isn't better engineers. It's automated checks that run before anything merges.

I built SlowQL to do exactly that. It's a SQL static analyzer, 171 rules across performance, security, reliability, compliance, quality and cost. Zero dependencies. Completely offline. Point it at your SQL files and it catches these patterns before they ship.

pip install slowql
slowql --input-file ./sql

It won't catch everything. It doesn't execute your queries or read your schema. But it catches the universal patterns - the ones in this article - statically, in CI, before they ever reach a table with 10 million rows.

If you've been on call at 2am because of a query that should have been caught in review, this is for you.

GitHub: https://github.com/makroumi/slowql

Conclusion and quick checklist:

Always EXPLAIN queries that will run on production tables.
Reject SELECT * in PRs; require explicit projections.
Add CI checks (static analysis, linting) to catch simple sargability and safety issues.
Prefer keyset pagination and index-friendly predicates.
Add functional/expression indexes only when necessary and after benchmarking.
Run realistic load tests on representative data sizes.

Canonical URL: https://makroumi.hashnode.dev/7-sql-patterns-that-look-fine-in-review-and-destroy-you-in-production

The Query That Looks Instant in Development and Destroys Production at Scale

Makroumi — Fri, 13 Mar 2026 10:50:39 +0000

Originally published at makroumi.hashnode.dev

You push the code on Friday afternoon. Tests pass. Staging looks fine. You deploy and go home.

At 2am your phone rings.

Response times are 8 seconds. Users are abandoning. The on-call engineer is staring at a dashboard full of red. And somewhere in the codebase is a query that ran in 4 milliseconds in development and is now bringing down production on a table with 50 million rows.

This is not a rare story. It happens every week at companies of every size. The query was never dangerous in development because development doesn't look like production. Different data volumes, different indexes, different query plans. The bug was always there. You just couldn't see it yet.

Why development lies to you

Your development database has maybe 10,000 rows. Your production database has 50 million. The query planner makes completely different decisions at different scales.

A full table scan on 10,000 rows takes 2 milliseconds. The same full table scan on 50 million rows takes 45 seconds. The query is identical. The environment is not.

This is why code review fails to catch these bugs. The reviewer runs the query locally, it's fast, they approve it. Nobody in the review process ever sees production scale data. The bug ships because the feedback loop is broken.

The patterns that are invisible in development

The leading wildcard

SELECT * FROM products WHERE name LIKE '%wireless%'

On 1,000 products this returns instantly. On 10 million products this performs a full table scan because a leading wildcard cannot use a B-tree index. It has to read every single row.

In development you have 1,000 products. In production you have 10 million. The query plan is completely different and you will never know until it's too late.

The function on an indexed column

SELECT * FROM orders WHERE YEAR(created_at) = 2025

You have an index on created_at. This query doesn't use it. Wrapping an indexed column in a function forces the database to evaluate the function for every row before it can apply the filter. The index is completely bypassed.

In development with 500 orders this is instant. In production with 20 million orders this is a full table scan that nobody saw coming.

The implicit type conversion

SELECT * FROM users WHERE user_id = '12345'

user_id is an integer. You're comparing it to a string. The database has to cast every value in the column before comparing. Your index on user_id is ignored entirely.

This works fine in development. It works fine in production until the table grows large enough that the full scan takes longer than your timeout allows.

The N+1 hiding in the ORM

orders = Order.objects.all()
for order in orders:
print(order.customer.name)

This looks like two queries. It's actually one query to fetch all orders and then one additional query per order to fetch the customer. With 10 orders in development that's 11 queries. With 10,000 orders in production that's 10,001 queries and your database is on its knees.

ORMs make N+1 invisible. The code looks clean. The query count is catastrophic.

SELECT * on a wide table

SELECT * FROM events WHERE user_id = 123

Your events table has 47 columns including several TEXT and JSON columns. You need 3 of them. SELECT * fetches all 47 columns for every matching row, transfers all of that data over the network, and loads it all into memory.

In development your events table has 200 rows. In production it has 200 million rows and this query is reading gigabytes of data you never needed.

On cloud warehouses like BigQuery or Athena you pay per byte scanned. SELECT * doesn't just slow you down. It charges you for every column you didn't need.

The moment everything changes

The reason these patterns are so dangerous is not just that they're slow. It's that they're invisible until they aren't.

Your query runs fine for months. Then the table crosses a threshold — 1 million rows, 10 million rows, 50 million rows and the query plan changes. What was fast yesterday is catastrophic today. Nothing in the code changed. Only the data.

The on-call engineer at 2am is not dealing with a new bug. They're dealing with a bug that shipped months ago and finally found the right conditions to detonate.

The feedback loop is broken by design

The fundamental problem is that static code review happens at development scale and production incidents happen at production scale. These two environments will never be the same and no amount of careful review can bridge that gap if the reviewer is running queries against a development database.

The only way to catch these patterns before they ship is to analyze the query itself, not the query's performance on a small dataset. Leading wildcards are always dangerous regardless of table size. Functions on indexed columns always bypass the index regardless of row count. SELECT * is always fetching more than you need.

These patterns don't need production data to be identified as dangerous. They need static analysis.

Catching these before they ship

SlowQL runs against your SQL files before they merge. It doesn't execute queries. It doesn't need a database connection. It reads the query itself and flags the patterns that are universally dangerous regardless of scale.

Leading wildcards. Functions on indexed columns. SELECT * in production queries. Implicit type conversions. Unbounded queries with no LIMIT. All of them flagged before the code ever reaches review.

pip install slowql
slowql --input-file sql/ --fail-on high

Add it to your CI pipeline and the query that would have paged you at 2am gets caught before it merges on Friday afternoon.

uses: makroumi/slowql-action@v1 with: input: sql/ fail-on: high

171 rules across performance, security, reliability, compliance and cost. Completely offline. Your SQL never leaves your machine.

github.com/makroumi/slowql

The query is already in your codebase

The pattern that will page you at 2am is probably already there. It shipped in a PR that looked fine in review. It ran fast in staging. It's been in production for months waiting for the table to grow large enough.

Static analysis won't catch everything. It won't replace EXPLAIN ANALYZE or query plan monitoring. But it catches the patterns that are universally dangerous before they ever reach a database, before they ever reach review, before they ever get the chance to detonate at scale.

The 2am page is optional. The query that causes it is not.

makroumi.hashnode.dev

The SQL query that ruined my weekend and what I built to prevent it

Makroumi — Mon, 09 Mar 2026 19:34:07 +0000

It was a Friday afternoon when the alerts started coming in.
Response times had jumped from 50ms to 8 seconds across the board. Other queries were timing out. The on-call engineer got paged at 2am. We didn't get back to a clean state until Sunday.
The culprit was a single query. SELECT * against a 10 million row table with no WHERE clause. It had passed code review. It looked fine. It wasn't fine.
That weekend I started writing down every pattern like it I'd seen cause a production incident. Not style issues, not formatting, the queries that actually hurt you.
Here's what the list looked like after two years.
The ones that kill performance
Leading wildcards are probably the most common. LIKE '%keyword%' looks harmless and works fine in development. What it actually does is tell the database it cannot use the index because it doesn't know what the string starts with. Every row gets scanned. On a small table you never notice. On a large one you've just written a query that gets slower every week as the table grows.
Function calls on indexed columns do the same thing silently. WHERE LOWER(email) = 'john@example.com' forces the database to apply the function to every row before it can compare. The index on email is useless. Write it as WHERE email = 'john@example.com' and store emails lowercased at insert time instead.
Implicit type coercions are the sneaky one. If user_id is an integer and you write WHERE user_id = '123' with a string, most databases will cast every value in the column to match your input type. Index bypassed, full scan, no warning anywhere.
The ones that cause data loss
DELETE FROM users is valid SQL. It will execute without complaint. It will delete every row in the table. There is no undo.
Same with UPDATE users SET status = 'inactive' with no WHERE clause. Every row gets updated. These happen in migrations more than anywhere else, someone writes the query, tests it on a filtered subset locally, forgets the WHERE clause, runs it on prod.
The security ones
Dynamic SQL is still showing up in codebases in 2025. EXEC('SELECT * FROM users WHERE id = ' + @userId) is a textbook injection vector. The fix is parameterized queries, always.
Hardcoded credentials in SQL files are more common than you'd think. UPDATE config SET api_key = 'sk_live_abc123' sitting in a migration file, committed to git, forever.
The cost ones
This one is specific to columnar and serverless databases like Athena, BigQuery and Redshift. These engines bill you per byte scanned. SELECT * on a wide table with 50 columns when you needed 3 means you're paying for 50 columns of data on every single query. At scale that adds up fast.
What I built
After two years of collecting these patterns I turned them into a static analyzer called SlowQL. You point it at your SQL files and it flags the issues before anything ships. 171 rules across security, performance, reliability, compliance and cost. Works offline, zero dependencies, plugs into CI as a pre-commit hook or a build step.
The philosophy is the same as any other static analysis tool. You don't wait for a JavaScript runtime error to find a type mismatch, you let the linter catch it at write time. SQL deserves the same treatment.
pip install slowql
github.com/makroumi/slowql
The patterns above are a small sample of what it catches. If you've been burned by something not on this list I'd genuinely like to hear it.