Nine places your database hides its slowest queries
Your database already knows which of its queries are the expensive ones. It has been keeping the list the whole time. The only reason you do not look at it more often is that every engine keeps it somewhere else, under a different name, with different columns.
Postgres puts it in pg_stat_statements, which is an extension you have to install first. MySQL puts it in performance_schema.events_statements_summary_by_digest. Oracle calls it v$sqlarea. SQL Server has sys.dm_exec_query_stats, and you have to CROSS APPLY sys.dm_exec_sql_text to find out what the statement actually said. Db2 has a table function. Snowflake has an information-schema function that takes a time range. ClickHouse has system.query_log, which records every query individually, so you have to group it yourself.
Nine engines, nine answers to one question, and the timings are in different units in most of them. MySQL reports picoseconds. Nobody remembers this. So the honest thing that happens is that you do not ask.
Ask once, in the same place, on any of them
SnoutData's Query Performance asks whichever one your connection has and shows the answer the same way every time: the statement, how many times it ran, the total time, the mean, the rows. Ranked by total time, because a query that takes 40ms and runs two million times a day costs more than the one that takes nine seconds and runs twice, and only one of those is the one people complain about.
The statements arrive with their literals normalised away, so one query run a million times with a million different ids is one row rather than a million rows. That is the engine's own doing on most of them; on ClickHouse we group by its normalised query hash to get the same result.
Where the engines really differ, we say so
Total time is the only ranking every engine can answer, so on most of them it is the only one offered. ClickHouse records more, so there the list can also be ranked by data read and by peak memory, and on a columnar database those are nearer to what a query cost than the clock is. A ClickHouse query that returns four rows can have read a billion, and the query that gets killed is the one that held the most memory, not the one that took longest.
The ranking is done inside the query rather than in the app, which matters more than it sounds: if you sort the top 25 by time and then re-sort them by bytes, you have the 25 slowest sorted by bytes, which is not the same list as the 25 heaviest readers.
SQLite, DuckDB, MongoDB and Pinecone keep no such record at all. Query Performance says that, rather than showing you an empty grid and letting you wonder whether it is broken or your database is idle.
Then hand it to the assistant
Finding the heavy query is the easy half. Select a row and the statement goes to the AI assistant with two buttons: Analyze, for what it does and why it is heavy, and Suggest optimization, for an index or a rewrite.
The assistant is grounded in your actual schema, it runs EXPLAIN itself rather than guessing at the plan, and anything it proposes to change is a statement you read and approve before it runs. Its advice is engine-specific too, because "add an index" is wrong on ClickHouse, which has no B-tree: there the levers are the sort key, a data-skipping index or a projection. On Redshift it is the distribution key. On SQL Server it might be parameter sniffing.
What this is not
It is not monitoring. SnoutData is a desktop app; it is not running when your laptop is shut. It does not sample your database, keep a history of its own, or alert you. Your database accumulates these statistics by itself whether or not SnoutData is open, and this is a window onto them: everything it shows you was already there.
There is a real product in continuous production monitoring, and it is a crowded one with good incumbents. This is the other thing: the question you ask on a Tuesday afternoon because something feels slow, answered in the window you were already in, by the database you were already connected to.