Your query looks fine. It still scans 116 million rows.
Your query looks fine. It still scans 116 million rows. SnoutData asks the database's own query planner before it runs anything, and warns you before a query full-scans a huge table, so a multi-minute mistake never leaves your screen frozen.
Some queries look perfectly clean and still read every row of an enormous table. Wrapping an indexed column in a function is the classic trap: WHERE DATE(created_at) = '2023-10-16' cannot use the index on created_at, so the database falls back to a full table scan. The awkward thing about this class of bug is that you have to already know it to avoid it.
The planner decides, not a model
This is not an AI feature. Before running a query, SnoutData asks the database's own planner how much it will read, and if you are about to scan a large table with no usable index, it stops and tells you first, with the estimated row count. The detection reads the real query plan and the real indexes, so it is deterministic, instant, and offline, and it runs on every query. No model, no tokens, no guessing. You stay in control: Run anyway, or Cancel. Nothing runs behind your back.
Advice while you type, and after you run
SnoutData flags the filters that defeat an index as you write them. A predicate like DATE(col), LOWER(col), a cast, or a leading-wildcard LIKE '%term' gets a marker in the editor with the reason and a rewrite that keeps the index usable. After a query runs slowly, an advice strip appears above the results naming what made it slow: a full table scan, a sort with no index, a temporary table. One button hands it to the assistant if you want the index or rewrite written for you, but the safety net itself never needs a model.
And a runaway query is always obvious
While a query runs, the toolbar timer turns into a clear "taking longer than expected" warning once it passes a few seconds, so a runaway never hides. One click cancels it. Every threshold is tunable, or you can turn any of it off, under the Large datasets settings.