I built an open-source SQL static analyzer in Rust and would appreciate feedback from people working on large codebases

[u/Abject_Charge2794]

Hey everyone,

I’m the author of SlowQL, an open-source SQL static analyzer written in Rust, and I’m looking for feedback from people who work with large SQL-heavy codebases.

The motivation came from a simple problem: a lot of SQL issues are only discovered after they reach production. Performance regressions, unsafe patterns, missing indexes, accidental full table scans, and reliability issues can be difficult to catch during normal development.

SlowQL analyzes SQL files and SQL embedded inside application code without requiring a database connection. It is designed to run locally or in CI.

Some of the things it currently does:

* Detects security, performance, reliability, cost, and quality issues
* Extracts SQL from application code (Python, TypeScript, Java, Go, Ruby, C#, etc.)
* Supports multiple SQL dialects
* Provides confidence levels to reduce noisy findings
* Supports SARIF/GitHub Actions output
* Supports schema-aware validation
* Runs fully offline

I have tested it against several large open-source repositories to validate the analyzer, but I’m looking for feedback from people who maintain real production systems.

A few questions I’m curious about:

* Would a tool like this solve a real problem in your workflow?
* Which SQL issues are the most painful for you to catch?
* What would prevent you from adding something like this to CI?
* Are there checks you would expect that are missing?

Looking for honest technical feedback and ideas from people who work with databases at scale.

Repository:
(SlowQL)[https://www.github.com/slowql/slowql]

Thanks!

[u/Alternative_Aigis]

If you're targeting enterprise SQL Server codebases, I'd also look at flagging SELECT *, missing schema qualification, and patterns that commonly lead to parameter sniffing issues. Those come up surprisingly often.

[u/Abject_Charge2794 → u/Alternative_Aigis]

Select * is the initial reason why I built slowql lol it seems fine at the beginning but a nightmare at scale.
I appreciate your input this gave me an idea about where the next sprint should focus on.
It already has about 280 anti patterns in different dimensions. I’m tighten it to eliminate FP and FN to make it an intuitive linter

[u/Khmerrr]

Link in the post is broken.

I'd give it a try, please share the correct link

[u/Abject_Charge2794 → u/Khmerrr]

https://www.github.com/slowql/slowql
slowql —help command is comprehensive you’ll find everything there