Readyset Docs

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.

A comparison result reading 622.8x faster with Readyset, with origin mean, P50, and P95 around 230ms against Readyset under 1ms for all three

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.