SQL Server Query Store on Mac and Linux

Jam SQL Studio reads a database's Query Store history over your existing SQL Server connection, compares the last period against the one before it with execution-weighted averages, and opens the compiled plans each period used — from the macOS, Windows or Linux build of the same desktop app. It is read-only: it never enables Query Store, changes capture mode, forces plans or clears history.

What you need before it shows anything

• A SQL Server 2016 or later connection (Azure SQL Database and Managed Instance use the same catalog views).
• Query Store enabled on that database by whoever administers the server. It is a per-database setting and off by default on most databases.
• VIEW DATABASE STATE on the database — or, from SQL Server 2022, the narrower VIEW DATABASE PERFORMANCE STATE.
• At least one completed collection interval inside the period you ask about.

Miss any of those and the workspace names the one that is missing instead of showing an empty grid.

What a regression looks like on the screen

The sample below comes from the synthetic fixture that ships with the app and drives its automated tests and screenshots. These are sample numbers from a fixture, not a measurement of anyone's database and not a claim about performance you will gain. It reproduces the shape the real-database test seeds against a live SQL Server: a 20,000-row Orders table, one parameterised query run first without a supporting index and then with one, at a one-minute Query Store interval.

One query, ranked first by duration, with 120 executions in each of the two 24-hour periods:

Both periods ran the query the same number of times, so the averages are directly comparable, and the plan column is what makes the row worth opening: the same SQL, a different compiled plan. Every average on that row is weighted by execution count rather than averaged across intervals — with unequal counts an average of per-interval averages can be off by two orders of magnitude, and the documentation works that arithmetic through.

Download Jam SQL Studio Query Store setup and workflow

Three jobs it is built for

1. Find candidate regressions

Pick a period (1 hour, 6 hours, 24 hours or 7 days) and a metric (duration, CPU time or logical reads). The workspace compares that period against the one immediately before it and ranks the queries by how far the metric moved. Queries with fewer than five executions in either period are labelled low sample instead of being presented as findings, and a query that did not run in the baseline is labelled new / no baseline rather than shown as an infinite increase.

2. Inspect the history behind the number

Selecting a query opens its full text, its query_id / query_text_id / context_settings_id and module, both periods' weighted duration, CPU and reads, the aborted and exception executions kept out of those averages, and the per-interval rows the averages were computed from. Boundaries are snapped to whole collection intervals and the effective UTC range is printed, so you can see exactly which intervals were included rather than trusting a rounded window.

3. Compare the compiled plans

Each period's plan ids are listed with their compile time, engine version and compatibility level. One click opens both estimated compiled plans in the plan compare view Jam already uses for execution plans. When the same plan ran in both periods the workspace says so and offers a single plan instead, because that change was not caused by a plan change and the investigation belongs elsewhere.

How this differs from Top SQL and the plan cache

Jam's Performance Dashboard has a Top SQL view, and it answers a different question. Top SQL reads sys.dm_exec_query_stats: a live view of what is in the plan cache right now, accumulated since the last restart or eviction, with no notion of yesterday. Query Store is persisted per-interval history written by the database itself; it survives restarts, keeps the plans that were compiled, and is the only one of the two that can answer "was this slower last week than it is today".

Neither one proves a cause. A metric that moved between two periods is an observed change; a different plan in the recent period is a candidate explanation, not a verdict. Data volume, parameter values, concurrency, statistics and hardware move the same numbers, and the workspace states that next to the comparison instead of implying a diagnosis.

Supported services and permissions

Read-only investigation. Every statement the workspace sends is a SELECT over the sys.query_store_* and sys.database_query_store_options catalog views, SERVERPROPERTY() and the metadata functions OBJECT_SCHEMA_NAME / OBJECT_NAME, run on the selected database's own pool. It never enables or alters Query Store, never forces or unforces a plan, never removes a plan, never clears history and never calls sp_query_store_flush_db. Statements are bounded to 60 seconds and Cancel sends a real attention signal to the statement running on the server (a cancel between statements stops the comparison before the next one is sent). Query text, rows and plan XML stay in memory; the tab remembers your filters, not your data.

Licensing

The Query Store workspace carries no cap of its own on either tier. Jam SQL Studio's Personal tier is free for personal, non-commercial use; Pro adds the commercial-use license for $9.99/month or $99/year and lifts the size caps on bulk operations such as export, import, backup and compare. The Query Store workspace is fully available on both tiers.

Open your own Query Store history

Install Jam SQL Studio on macOS, Windows or Linux, connect to SQL Server, and right-click a database → Query Store…