Query history

◐ in progress

Revisit recent results without rerunning a query just to see what happened last time.

Run a query, run another, and the first answer is still nearby. SQLly keeps a cache of recent runs, including the result rows and exact SQL, so you can revisit a previous result without executing it again.

The run history strip

After more than one run, a strip of chips appears above the results. Current holds the live run; retained runs appear newest first with time, row count, and elapsed time, such as “14:32 · 1,240 rows · 84 ms”. Select a chip to view that run read-only, return with Current, and pin or close each retained run as needed.

SQLly run history strip above the results grid — The run history strip: a Current chip and retained-run chips with time, row count, and elapsed, plus pin and close buttons.

What's cached per run

The SQL text that produced the run.
The result set(s) - columns and the actual rows.
Row counts, rows-affected, elapsed time, and completion time.

Bounded on purpose. For a spill-backed or incomplete run, or one whose rows exceed the history memory budget, SQLly keeps the counts and SQL but not the rows and explains why. History lives only in session memory; it is not written to disk or carried across restarts.

How many, and what's kept

How many runs - default 5, adjustable from 0 to 20 in Settings › Results, with a master on/off switch.
What counts as a new run - a capture mode controls whether a run is retained when the query changed, when the results changed, on either (the default), or only on both.
Eviction - the oldest un-pinned run drops off once you exceed the limit or the memory budget.
Pinning - a pinned run is protected from eviction. Pin the run you want to keep comparing against. If every retained run is pinned and the strip is full, SQLly hints to unpin one so history can stay bounded.
Scope - history is per editor tab; each query tab keeps its own runs.

Not to be confused with the query-history log. This run cache holds real results in memory for the current session. Separately, SQLly keeps a persistent local log of the SQL you've executed (statement text, target, outcome, and timing - no result rows) in its own database, which feeds the searchable History pane. One lets you re-view results; the other lets you find a statement you ran last week.