Comparisons
Run a query against your database and against a Readyset cache side by side, and see the difference in milliseconds rather than guessing at it.
What Readyset is
Readyset sits in front of PostgreSQL or MySQL and speaks the same wire protocol, so your application connects to it exactly the way it connects to your database. No driver change, no rewritten queries.
What it adds is caching that stays correct. Readyset follows your database's replication stream, so when a row changes, the cached results that depend on that row are updated. You are not choosing between fresh data and fast data, and there is no invalidation logic to write.
Most read queries are supported. Whether a particular one is worth caching is a different question, and that is what this screen is for.
Running a comparison
Compare with Readyset appears on every query in Queries, and Comparisons runs the same thing. RDST executes the query against your database and against a cache, then reports both.
You do not have to set any of that up. RDST deploys the Readyset container itself, points it at your target, waits for it to become healthy, runs the measurement, and manages the container's lifecycle afterwards. Docker running on your machine is the only requirement.

You get mean, P50, and P95 for both sides over the same set of samples. The aggregation above spends roughly 230ms on the database and comes back in under a millisecond from the cache, and the percentiles matter as much as the mean: a result that only improves the average is a different proposition from one where the whole distribution collapses.
Caching transforms some queries and does nothing for others. An expensive aggregation over data that changes occasionally is close to ideal. A primary key lookup already served from the buffer pool in under a millisecond has nothing to gain. Predicting which is which by reading the SQL is harder than it looks, which is the argument for measuring instead.
Reading the result
Two things will mislead you if you let them.
Unrepresentative parameters. A query tested with a value matching four rows will look spectacular and tell you nothing about the value matching two million. Use what your application actually sends.
A cold cache. The first execution against Readyset populates it, so that number is the miss rather than the steady state. RDST separates them, but it is worth knowing which one you are looking at.
Container management
The container RDST starts is reused for later comparisons against the same target, and released once you are finished with it. Nothing is left running, and there is no cleanup step for you to remember.
A cache started this way is for evaluating on your own machine. Putting Readyset in front of production is a separate exercise: see the Readyset Cache documentation.
A health check run with a duration does this across everything it captured and scores the workload as a whole. Comparisons is the per-query version of the same question.
From the command line
rdst cache deploy starts the cache and
rdst query cache-compare runs the
comparison, which is what you want for many queries at once or inside CI.
Queries
The registry of every query RDST has collected. Slow Queries, Health Check, and Ask all write here automatically, and anything in the list can be analyzed or compared against a Readyset cache.
Advanced
Code Scan, Agents, and Guards. Less-used tools that sit behind the Advanced section of the sidebar.