DEV Community: ReadySet

Less Work per Query: Speeding Up Readyset’s Text Protocol

ReadySet — Mon, 02 Nov 2026 00:00:00 +0000

Readyset is in the business of making your queries faster. If you are trying to improve your application’s performance, or reduce load on your database, one of the first things people will tell you is to use prepared statements. What if you can’t? Readyset’s latest release improves performance for ad hoc queries, and this post talks about some of the optimizations we made.

Why are prepared statements faster?

Prepared statements (sometimes "binary protocol”) are faster than ad hoc statements (sometimes "text protocol”) for a simple reason: they avoid repeating work. Instead of parsing, planning, and optimizing a query every time it executes, you do that work once in a PREPARE step. You get a handle to the prepared statement, and can EXECUTE it as many times as you want. You pay once for (most of) the work that is common to every statement execution, and each execution (mostly) only pays for the part that matters: actually getting the data.

Usually, by the time a customer comes to Readyset looking to soothe their database pains, they are already using prepared statements. The problem is, they require application changes. Many customers are trying to improve performance or reduce load on applications that are already legacy, or they don’t have control over (infra teams instead of dev teams), or for some other reason could not be expected to modify queries. That’s why we offer a transparent caching layer in the first place. However, until now, we have not spent much time optimizing our ad hoc statement path. So if one of those customers’ existing applications happened to be using ad hoc statements instead of prepared statements, they should still see Readyset’s signature massive speedup… but it wouldn’t be quite as impressive as the speedup they would get if they were also using prepared statements.

In our latest release, we have done some optimization of the text protocol path. We knew there would be overhead to trim down when each query arrives as SQL text that has to be handled afresh every time. We don't have space to discuss all ~12 significant improvements (depending on how you count), so this post will cover 4 interesting examples. Then, a sequel to this post will describe our new parse cache which is an even bigger jump and brings ad hoc query performance much closer to the prepared statement path.

To give you an idea of the scale of improvement just from these ~12 small changes: in a warmed cached point-read test with 1024 clients, this release handled about 2.7 times more throughput than the previous release when using ad hoc statements. That’s our fast case, and we care a lot about making it faster. But that difference only reflects a portion of all the changes. Often, stuff off the happy/hot path can matter just as much. (Have you ever profiled your error paths?) Anyway, let’s get started.

How does Readyset process a query?

I suppose if you want to understand the improvement we've made to handling queries when they reach the text protocol (or, for that matter, the first time you PREPARE them), we had better understand what the handling process looks like. Once we know which cache to hit and which key to look up, the cached-read path is already pretty well optimized. But getting from SQL text to that cache and key can involve quite a bit of work.

Readyset has two caching modes. Pull-based caching is a TTL-based cache of results retrieved from the upstream database. Push-based caching uses partially-stateful dataflow (Noria OSDI ’18) to maintain query results from database changes only for results you care about based on a CDC stream from the upstream database.

Reading those results starts with finding the corresponding cache, if one exists. This has to respect SQL semantics and things like schema search path/current database. Then we need the cache key: in a prepared statement, the values come from bound parameters, but for an ad hoc query, we have to extract literals from the AST and map them to cache key positions and values. Pull- and push-based caching use similar processes to identify the cache and key, and some parts are shared. (It doesn’t matter much, but technically the following examples assume a push-based cache.)

For example, with a users(id, name, active) table, Readyset needs to auto-parameterize the literal 42:

-- original SQL
SELECT * FROM users WHERE id = 42;
-- auto-parameterize
SELECT * FROM users WHERE id = ?;

Then it can look up the corresponding cache for that shape, and then look up the value for key 42. If this were a prepared statement, the 42 wouldn’t need to be auto-parameterized.

As you can imagine, there is a lot of complexity hiding in and around those “parse, rewrite, route" boxes in the diagram above. That’s why I very cleverly asked Claude to add an “etc.” box too. Session variables and current DDL state affect how a query is rewritten and what the lookup key should be, some literals should be auto-parameterized and not others, and so on. A more detailed diagram is at the end of this post, but even that mostly only calls out the boxes where we made improvements.

Why were we applying SQL rewrites that were no-ops?

Auto-parameterization isn’t the only SQL AST rewrite pass. Even for this simple query, we need to expand stars and resolve columns:

-- auto-parameterized
SELECT * FROM users WHERE id = ?;
-- normalize: expand stars, resolve columns, etc.
SELECT users.id, users.name, users.active
FROM users
WHERE users.id = ?;

This brings us to one of the ~12 improvements (depending on how you count) we made in this release: aren’t some SQL rewrites no-ops for some queries? For example, our support for subqueries in push-based dataflow relies on an “inline derived tables” rewrite. It might look something like this:

-- original SQL
SELECT *
FROM (SELECT * FROM users WHERE active = true) AS active_users
WHERE active_users.id = 42;
-- normalize: inline derived tables, etc. (parameters: 42, true)
SELECT users.id, users.name, users.active
FROM users
WHERE users.id = ? AND users.active = ?;

The rewrite passes have to do some fairly nontrivial work: resolve columns to the right table in the right subquery, pick aliases to avoid conflicts, move the inner filter into the outer filter, and so on. For more detail, see how Readyset rewrites SQL.

Our original point query doesn’t have a derived table, so it doesn’t need to do any of that work. In this case, it’s obvious. For some of our rewrite passes, it’s less obvious when it can be safely skipped, so we were applying the rewrites even when they were ultimately no-ops.

This was one of the first things to show up in flamegraphs when we started this optimization effort. But if all we had seen was “rewrites take a good chunk of the CPU cycles for each query”, we might nonetheless have looked elsewhere. However, this was surprising, because this was showing up in flamegraphs with point selects like the first example, too, not just arbitrary query workloads.

Optimization is all about deciding what to measure. This means both the specific observable metrics you collect and compare, whether you are profiling CPU or instrumenting memory allocations, etc.; but also the workload you run. We used a variety, and saw different problems become more prominent in flamegraphs, throughput measurements, lock contention, etc. depending on which workload was running. In this case, point selects generally represent the best case for the "parse, rewrite, route” part of processing a text-protocol query. As a result, looking at a flame graph for a point select with no derived tables and seeing the derived table rewrite taking up a non-negligible amount of time raised our eyebrows, and took us down that path.

Here is what the deep rewrites part of the flamegraph looked like profiling point select queries with and without skipping no-op rewrites, saving about 23% of CPU cycles on rewrites:

SQL rewrite CPU cycles per query. Hover or tap to highlght correlated frames.

Of course, that isn't going to affect queries that do need those rewrites, but most queries will at least skip some rewrites.

Why were unrelated tables affecting query latency?

The query itself isn’t the only part of the workload that matters. In a stateful system, state tends to accumulate. Could unrelated state impinge on the handling of a query? What happens if we run the same point select, but add a few hundred tables into the same database that the query doesn’t even reference?

To rewrite a query, Readyset needs information about table schemas. In our example, it needs to know which columns users has to expand SELECT *, and where id comes from. But the work we were doing to make that information available also depended on tables that had nothing to do with the query. Effectively, we were building a hashmap of all relations and all their columns before we started the rewrite passes. A point select against one table was building a hashmap for tens or hundreds of tables. We changed this to look up schema information as the rewrite needs it.

This also meant the larger your database, the wider the gap after it was fixed. With 500 unrelated tables, median latency dropped by 8x at a fixed query rate, and without the rate cap, throughput increased by 7x. Bet Marketing would love it if that were the headline! On the other hand, at 200 tables it’s the difference between 452 µs and 122 µs, and at 10 unrelated tables any difference was lost to run-to-run noise.

Throughput and latency by number of unrelated tables.

Why were we updating statuses that haven't changed?

After we’ve processed a query, Readyset will store (some might say "cache”) some information about it so we don't have to check again next time we execute it. Is there a cache? Should it go upstream? We store and retrieve that information in the QueryStatusCache. However, when we started measuring throughput under high concurrent load on the text protocol, we discovered we were taking a global write lock to update query status for an existing entry even when it hadn’t changed (and it rarely does). We had never noticed while optimization was focused on the binary protocol, because prepared statements would only take the write lock once at PREPARE time and then reuse the handle.

We simply added a condition to an if: check whether there is actually anything to change before taking the global write lock. Lock contention hazards like this often show themselves as a flattening (or worse yet, a cliff) in the throughput curve as concurrency increases, and in one benchmark we saw that starting as low as 96 concurrent clients. But that was with none of the changes in this release.

The previous graph was comparing release-to-release, where you can hopefully still see where specific areas of the product improve. But several different changes removed nonspecific throughput barriers like this one, so I honestly couldn't find a good way to isolate the effect of just this change, other than by hacking in a runtime toggle for that new if condition. That lets the effect of this change be seen more clearly, instead of leaving us at such low throughput that we wouldn't notice much of a difference. So although overall throughput under the same benchmark went up 2.7x from release to release, the portion due to this particular change was only ~18%: throughput at 1,024 clients went from 510k to 602k queries per second, and p99 latency fell from 4.18 to 3.68 ms. The throughput curve was able to go up further in this test, and the fact that without this guard (but with other changes) throughput is already going down from 384 to 768 means that although it was a small change on its own, it was a big part of the overall performance gain in this release.

Text-protocol throughput with the status guard off and on.

By this point we’re hitting the box’s CPU capacity and the curve is flattening out, with both the load generator and Readyset running on it. While I enjoyed measuring the impact of this 1 line diff on a shared box, you probably want to see how far the cached-read path can really go. For that, check out Marcelo’s post with separate load generators and a 10 Gbps NIC. That benchmark uses prepared statements (see the first paragraph of this post), so it’s measuring a different path from the text-protocol work here.

Why were we accumulating excessive query logs?

Similar to unrelated tables/queries affecting processing of one query, not all of the work we do for a query is needed to return a result. We also log query information asynchronously, so queries don’t have to wait for the logger. But what happens if queries produce that information faster than the logger can consume it? Seems like it should be unlikely, and we wouldn’t notice if logging is only on PREPARE. Plus... by the time we got to this item, ad hoc queries were a lot faster.

Without a bound on the queue, we could keep accepting queries while accumulating gigabytes of logging work. We bounded the queue, allowing some telemetry to be dropped when the logger falls behind. In an overload test, transient memory use just from the queue went from about 15 GB to 310 MB. Throughput also went up from 1.24 million to 1.35 million queries per second. About 4% of telemetry was dropped in that run. That’s a tradeoff, but life is full of tradeoffs.

Conclusion and results: how fast is Readyset’s text protocol now?

These might seem like odd examples for a post about making queries faster. It was mostly just not doing things we didn't need to. In fact, arguably much of these didn’t actually have to do with serving the query but with other tangential parts of the system (though we made plenty of other changes to the hot path too).

Okay, where did we end up? Well, at the risk of repeating the number 2.7 yet again… 2.7 times higher throughput! Specifically in the warmed cached point-select benchmark which was the worst case for text protocol overhead. At 1,024 clients. At 192 clients, median latency fell by 69%, p95 by 48%, and p99 by 20%. Yeah, I’ve picked these numbers out basically at random, and could have gotten pretty similar numbers from basically every benchmark we ran that didn’t use prepared statements.

Text-protocol throughput by client count; latency at 192 clients.

Bonus: can we make Readyset’s text protocol even faster?

Well, after harping about not doing stuff for so long, you must be convinced that laziness is indeed a virtue. And in a follow-up post, we’ll go another level deeper: what if we can avoid doing any of the work we just discussed, and make Readyset’s text-protocol performance even closer to the prepared statement path?

In the meantime, here is a more detailed diagram which shows the places we made some other noticeable improvements in this release.

Text-protocol query path. Hover or focus a numbered marker to highlight its component.

Commits on GitHub: 1. Read less schema, 2. Skip no-op rewrites, 3. Combine passes, 4. Streaming hashing, 5. Skip unused errors, 6. Faster schema access, 7. Skip unchanged updates, 8. Stamp only on change, 9. Keep logging bounded, 10. Connect with fewer trips, 11. Copy only samples, 12. Reuse result buffers.

Disclaimer: This post’s prose was machine-generated by a 36-key Beekeeb Piantor Pro operated by an artificially intelligent bio-appendage prone to hallucination. The diagrams’ SVG were handwritten by some people named Claude and Astra.

October Product Update 2026

ReadySet — Mon, 02 Nov 2026 00:00:00 +0000

October was a big release month at Readyset, with an exciting new RDST capability and the longest list of features and fixes we've shipped in a release this year. Let's catch up.

The RDST Agent Is Here

RDST now features an always-on agent that watches your Postgres or MySQL database for queries that are getting slower, busier, or changing plans, and flags them with a recommended fix.

The agent reads your database's query stats every minute and keeps a day-by-day record of each query shape. Instead of a lifetime average that buries yesterday's slowdown under three months of fast runs, it checks every five minutes whether each busy query is slower or busier than it usually is. When something changes, RDST agent investigates on its own: it runs EXPLAIN ANALYZE with real values from live traffic, explains what happened, and hands you the fix. Once you apply the fix, it confirms it worked.

In our walkthrough, a deploy made one query 30x slower. The agent flagged it within nine minutes, found the missing index, and confirmed the fix took the query from 184 ms to 3.8 ms.

Read-only, so it never writes to your database. Free and open source. Available now in the RDST desktop app.

Read the full launch post here.

💬 Product Updates

A quick naming note: Readyset's two caching modes, previously called shallow and deep caching, now go by pull-based and push-based caching, named after how each one keeps results fresh. A pull-based cache pulls new results from the database on a schedule, while a push-based cache has every write pushed into the cached results as it happens. Same products, just going by new names.

New Admin SQL Port for Readyset: Readyset now ships a dedicated admin SQL port. Admin sessions connect to the readyset schema instead of the upstream database, keep their own credentials, and run commands that affect Readyset itself rather than queries against your data. The first admin-only command, ALTER READYSET SHUTDOWN [RESET], lets operators shut down a Readyset instance, configure the port with --admin-address (default 127.0.0.1:6036) and --admin-credentials (default admin:admin), or disable it with --admin-address disabled.
Session-Variable Isolation for Pull Caches: A batch of fixes so pull cache entries no longer leak between sessions whose session variables would produce different query results. Pull cache entries are now keyed on the MySQL upstream's global value of the session variables that affect results, and on each PostgreSQL connection's IntervalStyle (whether inherited from the upstream or set in the session), timezone_abbreviations, and default_text_search_config. Sessions with different values now see their own cached results instead of each other's.
Dual-Password Support for MySQL: ALTER READYSET MODIFY USER ... RETAIN CURRENT PASSWORD keeps the old password valid alongside the new one, and ... DISCARD OLD PASSWORD retires it. Naming a user twice in --allowed-users starts a deployment mid-rotation. The readyset.users view reports rotations in progress in a new has_old_password column, so operators can run safe password rotations without a window where auth breaks.
Multi-Upstream MySQL and Smarter Connection Handling: --upstream-db-url and --cdc-db-url now accept a comma-separated list of MySQL servers, each with an optional |<weight> suffix. Added --upstream-connect-timeout to limit how long the adapter waits for an upstream connection, --client-connect-timeout-ms to disconnect MySQL and PostgreSQL clients that don't complete the handshake within 10 seconds by default, and --listen-backlog (default 4096, up from 128) so connection bursts are less likely to leave clients stalled until they time out.
Safer Memory Limit Defaults: --memory-limit now defaults to 80% of the memory available to Readyset (the container limit, if set) instead of unlimited. Set --memory-limit to 0 to keep the previous unlimited behavior). In push and push-then-pull cache modes, the pull cache now uses half of --memory-limit when --pull-memory-percent isn't set, instead of being unbounded.
Wider Pull Cache Coverage on PostgreSQL: Pull caches now serve queries over views created after Readyset started (previously these were never pull cached), and support point, box, path, and cidr values over the extended query protocol. Fixed a case where Readyset couldn't start in pull mode with RLS enabled against a PostgreSQL upstream whose certificate was signed by a private CA.
Faster Text Queries: Improved throughput for queries sent as text, which previously serialized on two locks: the schema catalog lock and another shared lock. Workloads with heavy text-protocol query traffic now see higher throughput under concurrency.
More Queries Served From Cache: A batch of fixes expanding what Readyset caches instead of proxying upstream. MySQL caches created with ? placeholders are now served from cache rather than sent to the upstream. Row comparisons with literals or placeholders on the left side (such as ($1, $2) = (a, b)) are now cached as lookups, and row comparisons mixing literals and columns (such as ('a', b) = ('c', 'd')) are now cached instead of rejected with a placeholder error. Push caches created from a query ID in SHOW PROXIED QUERIES using CREATE CACHE FROM <query id> are also correctly recreated on restart.

Plus 15 additional fixes and improvements. Check out the full release here.

New on the Blog & YouTube

Less Work per Query: Speeding Up Readyset’s Text Protocol

Michael Victor Zink writes about making Readyset’s ad hoc queries faster by doing less work per query (skipping no-op rewrites, ignoring unrelated tables, avoiding needless locks, and bounding the query log) for 2.7x higher throughput at 1,024 clients.

What Is a Wire-Compatible SQL Caching Proxy?

Caching SQL can live in two places: scattered through your application code with Redis, or in a layer that speaks the database's own wire protocol. The second option moves cache keys, invalidation logic, and the hit-or-miss decision out of the codebase entirely. This post walks through what wire compatibility actually requires at the MySQL and PostgreSQL protocol level, where Redis still fits, and why incremental view maintenance makes this different from a store you fill and empty by hand.

Readyset HA with ProxySQL and MySQL

Vinicius Grippa builds a highly available Readyset cache behind a 106 ms report query, using two docker run commands and two INSERT statements in ProxySQL's admin interface. Nothing changes in the application, the schema, or MySQL. The query drops to 0.716 ms, a 149x improvement, and the setup survives losing a Readyset node or a ProxySQL node with no downtime. Also covers the three ways to confirm the cache is actually serving reads instead of silently falling through to the database.

Watch: "Building the Invisible Cache"

Tanmay Sinha’s talk from MySQL BR Conf 2026 is now up on YouTube. His talk covers why the original MySQL query cache failed, why hand-rolling one on Redis leaves the hardest parts to your team, and what wire-compatible caching changes about that, and is followed by a demonstration by Vinicius Grippa.

Black October: What Actually Happened, and What To Patch

A primary-source review of the 28 "Black October" security incidents. Only two involved AI-driven attacks. The real damage came from long-lived credentials stored in platform environment variables and shared vendor systems. Includes the specific database-tier patches to apply this week and six steps for cutting credential risk.

A TTL Cache Needs To Know the Query

Marcelo Altmann on why cache-aside on Redis struggles with SQL once a workload hits real load: a key-value store can't re-run a query, so it can't refresh hot keys, collapse miss stampedes, weigh a 900 ms report against a 2 ms lookup, or key by session settings and user permissions. The strongest evidence for the argument comes from Redis itself, which ships two separate products (Smart Cache and Redis Data Integration) aimed at the exact gap.

Get Involved

Questions, bugs, ideas, or just want to say hi? Find us on Slack. Looking to contribute? Our newcomer issues are a good place to start.

A TTL Cache Needs To Know the Query

ReadySet — Thu, 29 Oct 2026 00:00:00 +0000

Plenty of teams cache query results with a TTL. A few seconds of staleness is fine for their workload and since a TTL is easy to reason about, this becomes the default solution. The trouble however, is the primitive underneath. Cache-aside on Redis is the default way to cache SQL and it's built on a basic primitive, a simple key-value store that holds bytes. We hold the view that a SQL query cache should not only hold the results, but also the query that generated them and preferably additional metadata. When running a cache under load, refreshing a hot key or deciding what to evict becomes infinitely easier if the cache is able to run the query again and reconstitute the cached results on demand.

Since a TTL cache built on Redis or Memcached doesn't know what a query is, it can't re-run one to refresh a hot key, collapse a burst of misses into a single call, or differentiate a 900 ms result from a 2 ms one. That work is left up to your application.

We've written before about why key-value stores struggle to cache relational data when freshness is the goal. This piece covers the other case where some staleness is acceptable, and the cache still needs to know the query to hold up under load.

A note on names. Readyset has two caching modes, which we used to call shallow and deep caching. We now call them pull-based and push-based caching, after how each one keeps results fresh. A pull-based cache pulls new results from the database on a schedule, while a push-based cache has every write pushed into the cached results as it happens. The products are the same, and earlier posts use the old names.

Adding hardware is a harder way out than it used to be. Memory and storage are getting pulled toward AI workloads, prices are up, and some regions have no data center capacity left to sell. Database bills are climbing faster than traffic, so getting more out of the database you already run is worth real engineering effort.

All of this matters more every month. A growing share of the SQL hitting production databases is written by agents at runtime, and for those queries there's no read path to wrap at all. We'll come back to that at the end.

What a key-value store knows about your data

Very little. Redis is very good at its job, it stores values under keys and serves them fast, but it doesn't know if a SQL query produced the value, which tables that query read, how long the query took to run, which session settings shaped it, or who is allowed to see it.

A cache-aside implementation fills the gap in application code. Every read path in the application checks the cache, runs the query on a miss, serializes the result, and writes it back with a TTL. Each of those steps is a decision your team makes by hand, query by query.

A query cache starts from the query. Readyset sits between your application and the database, holds the SQL and a database connection, and can run a query on its own. That's the key difference: a cache that can run the query can refresh it, coalesce misses on it, and put a price on it for eviction, while a key-value store can only hold what you hand it.

Outside databases, caching already works in this way. A reverse proxy like Varnish, or a CDN, keeps the URL, so it can refetch from the origin, serve a stale copy while it refreshes (HTTP's stale-while-revalidate), and collapse a burst of misses into one origin request. Readyset's pull-based cache does the same for SQL.

	Cache-aside on a key-value store	Readyset pull-based cache
What it stores	Bytes your app serialized, under a key your app chose	Query results, keyed by SQL, parameters, schema, and session settings
Read path	Cache-aside code in every read: check, query on miss, serialize, write back	Unchanged; the app sends SQL as before
On a miss	Your app runs the query and fills the cache	Readyset forwards the query to the database and fills the cache
Refresh	A job you build, since the store can't run a query	Readyset re-runs the query in the background
Stampedes	A lock you build	Concurrent misses collapse into one query
Eviction	LRU or LFU, access patterns only	Weighs size, query cost, and read frequency
Session and tenant safety	Only as good as your key design	Session settings and security context are part of the key

Where a TTL cache falls short

We ran into each of the problems below while building Readyset's pull-based cache, which we introduced earlier this year under the shallow cache name. The first four form a chain: fixing one exposes the next, so they have to be solved together. The last four show up in every TTL cache regardless. Every fix depends on something a key-value store doesn't have.

1. Hot keys expire under load

A fixed TTL forces a specific tradeoff. To bound staleness, every entry expires at its deadline, including a hot key read thousands of times a second. When it expires, every request for that key misses and goes to the database until one repopulates the cache. Latency on that key goes from under a millisecond to tens or hundreds of milliseconds. The p50 looks fine. Users feel it at p99, and a page that runs several queries only needs one of them to miss.

This is also one reason why hit rate is not always the right metric to watch. It averages over every request, and the requests that hurt are a tiny sliver, the ones that land on a hot key in the moments after it expires. A cache can report 99% hits while nearly all of its slowest responses come from a few misses. Because they cluster on your most popular keys, they cluster on your most popular pages. Watch p99 latency on cached queries instead.

What teams do today: accept the spikes, or lengthen the TTL and accept staler data.

Readyset: the TTL counts from the last read, not from when the entry was created. A key your application keeps reading stays cached and its latency stays flat. Keys that go quiet, age out and free memory. Uses: read tracking per cached result.

2. Hot keys that never expire go stale

Sliding TTL fixes the spike but it opens a new gap. A key that's read constantly never expires, so it can sit in the cache indefinitely while its data changes underneath it. A refresh also takes time. The query runs as long as it did the first time, so it has to start early enough to finish before the result goes past its staleness limit. For a 900 ms query, that lead time is real.

What teams do today: this problem only appears once expiry is sliding, which is why most TTL caches stay fixed and keep the spikes from problem 1.

Readyset: while a key is still being read, Readyset re-runs its query against the database and swaps in the new result. A request that finds an entry due for refresh gets the cached value immediately and queues the key. All of it runs on Readyset's own internal workers, off the request path.

3. Refresh multiplies database load

Once refresh exists, a hot key with thousands of readers can trigger thousands of refreshes.

What teams do today: nothing, because without refresh there's nothing to deduplicate.

Readyset: one refresh per key is in flight at a time. A hot key results in a single database query no matter how many readers it has.

4. One refresh schedule fits nobody

Keys change at different rates. Some results move (i.e. they are updated) every few seconds, while others sit unchanged for days. Fine-tuning the TTL for caches to match its update rate is a manual process, and not to mention that it changes often. The result is a query that might get evicted out too soon, or a query that is constantly refreshed even though it's not being updated frequently in the database. A single schedule spends database capacity on data that hasn't moved and lets the volatile keys fall behind.

What teams do today: pick one TTL for everything, usually tuned for the most volatile data, and pay for it in database load.

Readyset: each refreshed result is compared with the previous one. Keys that changed get refreshed sooner, keys that didn't get refreshed later, and a load limit caps how much refresh traffic the database sees at once. In our Adaptive Cache benchmarks, this cut p95 staleness by 97% compared with a straight TTL, for about 10% more refreshes. Uses: each key's history of changes.

5. Misses arrive all at once

Refresh covers keys already in the cache. A new or evicted key still starts cold, and if hundreds of requests ask for it in the same instant, they all run the same expensive query. That's a cache stampede.

What teams do today: absorb it with database headroom, which is capacity paid for and idle most of the time.

Readyset: concurrent misses on one key collapse into a single upstream query. The rest wait for that result.

6. Eviction drops the wrong results

LRU and LFU look only at access patterns. A 4 KB result counts the same as a 4 MB one, and a 900 ms analytical query the same as a 2 ms lookup. When memory fills, the store can throw out a result that took a second to compute to make room for one that takes two milliseconds. LRU was designed for memory pages, where every entry is the same size and costs the same to bring back. That assumption holds for a CPU or an operating system's page cache. It breaks for query results, where one entry can be a thousand times larger or slower to rebuild than its neighbor. Evicting by recency alone treats a 900 ms report and a 2 ms lookup as interchangeable, and they aren't.

What teams do today: add memory until eviction rarely happens.

Readyset: every entry records its size and how long its query took on the database. At the memory limit, Readyset weighs those against how often the entry is read. A new result gets in only if it's worth more than what it would push out, so a burst of cheap one-off queries leaves your expensive results in place. Uses: result size and query cost.

7. The same query returns different answers

The same SQL with the same parameters can return different results depending on the session. Character set and collation change how text compares and sorts. Timezone changes how timestamps come back. SQL mode decides what happens on division by zero or an invalid date. A key built from the query and its parameters ignores all of that, and a session gets a result meant for someone else's settings.

What teams do today: mostly nothing. It rarely shows up until two clients with different settings share a cache, and then it looks like a data bug.

Readyset: the key includes the statement, its parameters, the schema it resolves against, and the session settings that affect the result. A hit returns what the database would have sent to that session. Collation alone has plenty of edge cases; we wrote up how Readyset handles them. Uses: the session's settings, seen on the wire.

8. The cache doesn't know who's asking

A key-value store hands the value to anyone with the key, including a user whose access was revoked an hour ago. Under row-level security, the same SQL returns different rows for different users, which is why most caches skip it.

On a key-value store: permission checks in every read path and per-tenant key namespaces.

Readyset: it checks each user's permissions when the query is first created, keeps it up to date by querying the database every 5 minutes, stores a local copy, and consults it before returning data. When it isn't sure, it forwards the query to the database. For RLS, it folds the security context, such as the user ID or a JWT claim, into the cache key. If it hits a policy it can't interpret, it doesn't cache that query. Uses: the database user and security context behind each query.

What knowing the query makes possible

Every fix above comes from the same place. Readyset sees each query on the wire, so it knows things about a cached result that a key-value store never will.

The result is a cache that keeps p99 latency flat under load, while background workers keep results fresh at the right interval for each one. That's what a TTL cache was supposed to be. It needs the query to get there, and your application keeps sending SQL exactly as before.

What about Redis's own answers?

The strongest evidence for this argument comes from Redis itself. It has shipped two products aimed at exactly this gap: one teaches Redis about SQL queries, and one keeps Redis in sync with the database. A company builds those because its customers keep running into the limits of a plain key-value store.

Redis Smart Cache wraps your JDBC driver and caches SQL results in Redis without code changes. It records access frequency and mean query time, and caching is driven by rules you configure per query. Because it's a JDBC wrapper, it covers JVM applications; a Python, Node, Go, or Ruby service needs something else. Freshness is still rule-based TTL on top of Redis.

Redis Data Integration (RDI) uses change data capture to copy rows from your database into Redis hashes or JSON documents, typically within seconds. That keeps rows fresh, but it replicates tables, not query results. Your application now reads a Redis data model instead of sending SQL, so joins, filters, and aggregates move into application code or pipeline transforms. Per Redis Cloud's docs, it assumes the app can tolerate eventual consistency.

Readyset takes the third path: keep the SQL, keep your driver in any language, and put the query-aware work in a proxy between the application and the database.

When a few seconds of staleness is too much

Some workloads can't accept any staleness. For those, Readyset has a second mode: push-based caching. Instead of pulling fresh results from the database on a schedule, it pushes each write into the cached results as it happens. It's built on Noria, a dataflow system developed at MIT and presented at OSDI '18.

When you cache a query, Readyset turns it into a graph of SQL operators ending in a node that holds the result set. It follows the database's replication stream and turns each INSERT, UPDATE, and DELETE into a delta that flows through the graph. Each operator touches only the affected rows, and the cached results change in place. The graph holds only the keys your application has asked for.

There's no invalidation logic to write and no TTL to tune. Write-heavy tables stay cached too, since each write costs only the rows it touched. And unlike row-level CDC into a key-value store, what stays fresh is the query result itself, joins and aggregates included.

For more on this mode, see Don't use key-value stores to cache from relational databases and Cache invalidation for SQL queries.

Agents make the case stronger

Everything above assumes a person wrote the read path. That assumption is fading. A growing share of the SQL hitting production databases is written by agents at runtime, and that changes caching in four ways.

Cache-aside has nothing to wrap. Cache-aside works by putting cache code around a read path a developer wrote. An agent's query doesn't exist until the model writes it, so there's no function to wrap and no place to put the check, the miss handling or the key design. Only a cache that sees the SQL itself can cache an agent's reads at all. For agent traffic, the query is the only thing there is, which is the argument of this piece taken to its end.

Nobody can pick the hot queries in advance. In an app written by people, the set of read paths changes at release speed, and someone can keep the cache list roughly current. Agent queries change with every prompt. The workable way to decide what to cache is to watch live traffic and rank queries by the load they put on the database, which is what QueryPilot does.

Agent traffic has the shape that breaks naive caches. Agents fan out: parallel sub-agents and concurrent sessions often ask for the same data at the same moment, which is a stampede by another name. They also explore, firing off one-off queries that would flush an LRU cache of the expensive results everyone else depends on. Request coalescing and cost-aware eviction were built for exactly these patterns.

A wrong answer becomes a wrong action. A person looking at a slightly stale dashboard usually notices. An agent takes the stale number, acts on it, and hands it to the next step. The session and permission problems get sharper the same way: an agent acting for one user that receives another user's cached rows is a data leak with no person in the loop to catch it. Session-aware keys, RLS-aware keys and permission checks become requirements. For reads that drive actions, push-based caching keeps results current as writes arrive; pull-based caching covers exploratory reads where a few seconds of staleness is fine.

This is also where database load is heading. Agents don't wait for a page to render or log off at night, and their query volume grows with the number of agents, not the number of users. With hardware scarce, that load has to come off the database somewhere, and a cache that knows the query is the only kind that can take it.

We'll be honest about what we don't know yet, how cacheable agent SQL is in practice. Our internal tests indicate that it's very repetitive. About 40% of queries are duplicates and cacheable in agentic workloads as per our internal testing. Many agents run the same playbooks at the same time, so they ask for the same data with different parameters. Many don't write free-form SQL at all; they call tools that wrap fixed queries. And agents break big tasks into many small follow-up lookups, which repeat far more often than one-off reports. The open question is free-form text-to-SQL, where two agents can ask the same question in differently shaped SQL. We've started tagging agent traffic in our proxy to measure this, and we'll publish what we find.

One connection string

Both modes sit behind the MySQL and PostgreSQL wire protocols (here's how a wire-compatible caching proxy works). Making an application cache-aware usually means building against a cache API and rewriting every read path; we've seen teams spend six months to a year on that work. With Readyset, it's a connection string change, in any language.

Keep Redis for sessions, counters, and queues. For query results, use a cache that knows what a query is.

Try it at readyset.io.

Black October: What Actually Happened, and What To Patch

ReadySet — Tue, 27 Oct 2026 00:00:00 +0000

Black October is the name social media gave to a wave of security disclosures in October 2026, including PHP2Shell, the Railway and TiDB Cloud breaches, and the LiteLLM supply-chain attack.

Most of the "AI is hacking the internet" stories are about AI finding bugs, not exploiting them. The breaches that hurt database teams came from long-lived credentials stored in shared places. Here's what we found and what to do this week.

The short version

Most of the AI in this story works for defenders. Vulnerability disclosures doubled this year, and AI tools found the most serious bug on the list before it was widely exploited.
AI-driven attacks are real but rare. Only two of the 28 incidents involve an AI-driven attack, and the evidence for one of them is weak.
Stolen credentials did the real damage. Railway, Zeabur, TiDB Cloud, and LiteLLM all came down to long-lived keys stored in one place.
Your next step: Patch the software next to your database, and rotate any database credential stored in a platform's environment variables.

What was Black October?

Black October was a burst of alarm in mid-October 2026, when a list of 28 security incidents spread on Reddit and X. One post said AI agent swarms were hacking about half the internet. Another said a new CVE (Common Vulnerabilities and Exposures entry) was dropping every hour.

The panic follows a familiar plot. In The Hunt for Red October (1990), the Soviet Union launches a new submarine with a drive so quiet that sonar can barely hear it. When it heads for the US coast, both governments assume its captain, Marko Ramius, plans to attack. One analyst, Jack Ryan, reads the same evidence and reaches the opposite conclusion: Ramius is defecting and bringing the submarine to the West.

Black October has the same shape. A powerful new capability, AI that finds software flaws at scale, showed up all at once, and the first reading was that it was being turned against everyone. The evidence mostly points the other way. Like Red October, the alarming new arrival is largely on the defenders' side. The damage this month came from something older and quieter.

We took Ryan's approach. We checked each incident against primary sources and sorted it by what AI actually did. Then we searched security news for critical incidents that the list missed. We build Readyset, a SQL proxy that sits between applications and Postgres or MySQL, so we focused on those databases and the credentials that reach them.

How many of the 28 incidents actually involved AI?

Nine of the 28 incidents have a documented or possible AI connection, and none was traced to AI-written code. The other 19 have no documented AI link.

Readyset review of 28 incidents from the viral Reddit list, primary sources, as of October 22, 2026 (full table in the appendix)

The sources show two more patterns:

Some of it is old news. The Medi-Cal billing-vendor breach happened in October 2025. The AOMEI update tampering ran from May through July. Palo Alto patched its GlobalProtect bug in May, and the North Korean campaign started in July 2025. SecurityToday found that many of the attacks began weeks or months earlier.
Some numbers grew in the retelling. eMudhra's "master keys" were eight intermediate certificates that never issued a website certificate. Railway said an attacker "may have" reached customer secrets. Zeabur's 321,810 figure counts account records read from a database, not accounts taken over. Cairn's "100+ companies" is an estimate based on token spending.

The closest case of AI-written code isn't on the list. UpGuard found more than 16,000 misconfigured Supabase databases, most with row-level security turned off. UpGuard attributes most of them to apps built with AI coding agents, but says its scan can't prove that for any single site.

Is AI really finding more bugs?

Yes. AI tools got very good at finding bugs this year, and defenders use them the most.

One scene in the film captures what that feels like. Red October's quiet drive confuses the US sonar computer, which logs it as "magma displacement," a natural sound. Sonar operator Seaman Jones plays the recording 10 times faster and hears a machine. Better sensors put more contacts on the screen, and the work becomes telling them apart. That's where the security industry is now:

Disclosures doubled. The US National Vulnerability Database (NVD) logged 72,812 CVEs from January through September, more than in all of 2025. September alone had 14,943, compared to 4,321 a year earlier.
AI found the most serious bug on the list. PHP2Shell lets an unauthenticated attacker run code on any web server that runs PHP, through code that dates back to 2012. Calif and Wiz each found it, both using the same OpenAI model. OpenAI says AI found it before attackers did. But Amazon's honeypots logged an exploit attempt four days before disclosure, and a leak forced the patch out a day early.
AI tools appear in vulnerability credits. The Node.js Brotli fix credits OpenAI Codex Security. Microsoft's October Patch Tuesday fixed about 1,411 flaws, a record that the press links to Microsoft's own AI bug hunting. Anthropic's disclosure dashboard lists 219 CVEs and 365 GitHub security advisories.
Attackers use few of these bugs. VulnCheck counted 225 CVEs credited to Anthropic's program as of late September. Attackers have exploited one.

Maintainers carry the cost. PostgreSQL 19 moved to November 19 and dropped several major features. The project cites the volume of fixes to older branches, and press coverage ties that volume to AI-assisted code review. curl will publish low- and medium-severity reports openly starting October 26 because its maintainers can't keep up.

If you run Postgres or MySQL, patch on a tighter schedule than you did a year ago. Rapid7 reports that attackers now exploit high-severity bugs about three days after disclosure, on average.

Have AI agents actually run attacks?

Yes, but the confirmed cases are fewer, and stranger, than the X posts suggest.

A lab's own agents caused the Hugging Face incident. The "swarm" that people cite came from OpenAI's test environment. According to OpenAI, agents running a hacking benchmark with reduced safeguards couldn't solve some tasks and went looking for answers. They broke into OpenAI's own artifact server first, then reached Hugging Face in July. About 1,200 agents were involved. In May, agents that OpenAI was testing also pushed malicious packages to RubyGems.

Criminals use agents to scale up. In the Cairn campaign, attackers aimed an open-source multi-agent platform at more than 1,200 websites. The agents tried to plant web shells, which are scripts that give an attacker remote control of a server. Reuters named Deere, SharkNinja, and Cummins among the targets, and each reported limited impact. The attackers also left their own control panels exposed, leaking hundreds of credentials. Anthropic's September threat report describes one group running Claude Code workflows with little human input, and another that scanned 1.8 million Android apps for hard-coded secrets.

These agents went after known web bugs and exposed secrets. They didn't invent new kinds of attacks. They made old attacks cheap enough to run against everyone at once.

Where did the real damage come from?

The incidents that hurt database teams this month share a pattern: one long-lived credential, stored in one place, that opened many systems. The weak spots were systems nobody watches closely: the platform that stores your environment variables, your CI/CD (continuous integration and delivery) server, a vendor's control plane, or a laptop with a .env file.

Incident	How attackers got in	What they could reach	Time inside
TiDB Cloud	A stolen service-account credential	Account data, SQL editor text, and encrypted management API keys	About four weeks (Sep 9-Oct 7)
Zeabur	Leaked long-lived AWS keys and a cluster admin token that never expired	3.2 million environment-variable records and possible access to 865 database services	Oct 14-15, its second breach since August
Railway	Not disclosed	Customer environment variables, which can include database credentials; some were decrypted	Detected Oct 21
LiteLLM	GitHub CLI tokens stolen from three engineers	A stealer that took `.env` files, `psql` and `mysql` shell history, and keys found through `DATABASE_URL`	About two hours live on PyPI
UpdraftPlus	A breach of the vendor's own website	Connection keys to customer WordPress sites that never expire	Oct 18-19
OVHcloud CLI	A contributor's GitHub account, compromised since March	Release files for five versions of the tool	About 94 minutes of bad downloads

The pattern shared by the Railway, Zeabur, TiDB Cloud, and UpdraftPlus incidents

Zeabur's own report says its admin credentials were long-lived, stored in plain text, and usable from the public internet. Railway says its incident is one of a series aimed at hosting platforms, with AI inference providers as the final target. A researcher traced cryptocurrency thefts that used keys stored on Railway to about two hours before Railway's disclosure.

TiDB Cloud matters most to us because it's a managed MySQL-compatible database. PingCAP found no sign that the attacker touched data inside customer databases, and it hasn't asked customers to change database passwords. But the attacker did get text that people typed into the web SQL editor. If anyone on your team pasted a connection string or password into a hosted SQL console, assume that someone else has it.

What should you patch and rotate this week?

Patch PgBouncer, your database, and the app-tier software next to it, then rotate every database credential stored in a platform's environment variables. The details follow.

Patch these components

The list starts with the database tier.

Component	Update to	Why it matters
PgBouncer	1.26.1	A client with one user's password can sign in as any other user that uses SCRAM password authentication, including superusers. Two other bugs let an unauthenticated client freeze it.
MySQL	October Critical Patch Update (8.4.13 for the 8.4 line)	Quarterly MySQL fixes; version 8.4 is affected through 8.4.12
MariaDB	10.6.28, 10.11.19, 11.4.13, 11.8.9, or 12.3.3	MariaDB published 15 CVEs on October 9 and 16, including three rated 9.9. The fixes shipped in the summer releases, so confirm that you have them.
pgvector	0.8.7	Buffer overflow when it builds IVFFlat indexes
PgJDBC	42.7.14	Two CVEs in the Java driver
PostgreSQL	18.6, 17.11, 16.15, 15.19, or 14.24	No October release, but the August release fixed 28 CVEs. If you skipped it, update before the November release.
PHP	8.5.12, 8.4.27, 8.3.36, or 8.2.35	PHP2Shell lets attackers run code on the app servers that hold your database credentials.
GitLab	19.5.1 or its backports	Two bugs rated 10 out of 10. CI/CD variables often hold production database credentials.
Node.js	22.23.4, 24.22.1, or 26.12.1	Brotli decoder bug, plus fixes for TLS hostname checks
NGINX	1.31.7 or 1.30.6	Three memory bugs, each needing a specific configuration (alias, AIO with SSI, or a regex map)

If any computer installed LiteLLM 1.107.0 on October 21, treat it as compromised. Rotate every credential it could read, including database passwords.

Reduce credential risk

Rotate every database credential that you've stored in a hosting platform's environment variables, a CI/CD system, or a hosted SQL console.
Switch to short-lived credentials where your platform supports them, such as cloud identity and access management (IAM) database authentication or dynamic secrets from a vault.
Create a separate database user for each service and each AI agent, with only the access it needs. Don't let agents use the application's sign-in. The same goes for any proxy in the path: Readyset, PgBouncer, or ProxySQL should each connect with its own user, not the application's.
Block public internet access to your database, and require TLS.
Turn on audit logging for your database and for any control plane that manages it.
Store backups offsite, and make them immutable. The SafePay advisory describes attackers resetting backup appliances and deleting backups before they encrypt data.

Per-agent database users get hard to manage once you have more than a few agents. That's the problem we're building Readyset Guard to solve: it applies per-agent access policies at the proxy, so each agent gets only the queries and data it should.

One ping only

The film ends well because Ryan read the evidence instead of the noise. Near the end, Ramius asks for "one ping only": a single sonar pulse that shows exactly where he is after hours of guessing on both sides.

That's the standard we'd hold this month's coverage to. The AI story is mostly good news: AI is finding old bugs faster than attackers, and patches are shipping. The part that cost people data and money was quieter. It came in through keys that had sat in the same place for months.

Patch what sits next to your database, and spend an afternoon on the systems nobody watches. You'll learn more there than from the news feed.

Appendix: All 28 incidents

We checked each incident against primary sources where they exist. Relevance means relevance to teams that run Postgres or MySQL.

#	Incident	When	What AI did	Relevance	What the list got wrong
1	PHP2Shell	Fixed Oct 21	Found the bug	Medium-high	Understated it. "70%" is PHP's share of websites, not the share that's vulnerable.
2	eMudhra	Oct 20	Found it (weak link)	Low	Intermediate keys, not root keys. None issued a website certificate.
3	California students	Access May-Sep; notice Oct 19	None	Low	The breach was at ETS, the testing vendor.
4	Railway	Oct 21	AI keys targeted	High	Railway says "may have accessed" and gives no count.
5	Zeabur	Oct 14-17	AI keys targeted	High	Counted 321,810 records read, not accounts taken over.
6	LiteLLM	Oct 21	AI tool compromised	Medium-high	The bad release was live for about two hours.
7	GitLab	Oct 12 and 21	None	Medium	Merged two separate bugs rated 10 out of 10 into one.
8	Cairn	Sep 25-Oct 19	Agents ran the attack	Medium-high	"100+" is an estimate based on token spending.
9	Ahold Delhaize	Oct 11-12	None	Low	The company took systems offline itself, and stores stayed open.
10	Onamae.com	Oct 20-21	None	Medium	One VPS product. 26,739 servers were possibly affected.
11	Signal	Fixed Sep; CVE Oct 20	None	Low	A malicious caller has to trigger it.
12	NGINX	Oct 14	None	Medium-high	Rated 8.1 under CVSS 3.1. Each bug needs a non-default configuration.
13	HTTP/3 QPACK	Oct 22	None	Low	Affects HTTP/3 libraries, not mainstream web servers.
14	Plex	Exploited from Oct 17	None	Low	Patched in August. Only unpatched servers are at risk.
15	SafePay	Oct 20	None	Medium	600+ victims, but not all are critical infrastructure.
16	Palo Alto GlobalProtect	Bug from May; update Oct 19	None	Medium-high	An old bug with a new ransomware attribution.
17	Bullhorn	Oct 16-19	None	Low-medium	Accurate
18	Medi-Cal	Breach Oct 2025	None	Low-medium	A billing vendor, and a year old
19	UpdraftPlus (WordPress)	Oct 18-19	None	Medium	Accurate
20	AOMEI	May-Jul; disclosed Oct 16	None	Medium	Months old
21	Meta Muse	Oct 20-21	AI product leaked data	Medium	Shared chats only. No misuse seen.
22	Tor relays	Aug-Oct 20	None	Low-medium	Hacked exit relays stole SSH passwords, not general sign-ins.
23	TiDB Cloud	Sep 9-Oct 19	None	High	The attacker's 10.6 TB and 180,000-organization claims are unconfirmed.
24	State Bank of India	Oct 21	None	Low	3,897 records confirmed. SBI hasn't confirmed a breach of its systems.
25	OVHcloud CLI	Oct 19	None	Medium	Accurate, but nobody has analyzed the payload.
26	Siemens Software Center	Oct 15-19	None	Low	An installer app, not industrial systems
27	North Korea (Lazarus)	Since Jul 2025; Oct 21	Attack (weak link)	Low	Not new. The AI link is one generated photo.
28	Node.js Brotli	Oct 21	Found the bug	Medium	Code execution was shown only on a weakened build.

What the list missed

Database and credential items come first.

Incident	When	What AI did	Why it matters
PgBouncer SCRAM bypass	Oct 14	None stated	Lets a client sign in as any SCRAM user, including superusers
MySQL October patch update	Oct 20	None stated	Quarterly MySQL fixes; 8.4 is affected through 8.4.12
MariaDB	Oct 9 and 16	None stated	15 CVEs published, three rated 9.9; fixes already shipped
pgvector	Oct 5	None stated	Overflow when it builds indexes
Supabase exposure	Sep 28	AI-built apps, probably	16,000+ readable databases, most with row-level security turned off
OpenCode Console	Oct 16-17	AI keys targeted	Stored LLM API keys may have been exposed for about 1.4 percent of users.
Atlassian Data Center	Patched about Oct 6	None	Unauthenticated file read that leads to admin access, exploited within hours of a public write-up
BeyondTrust Remote Support	Fixed Oct 8	None	A zero-day exploited since August
Ivanti Connect Secure	Oct 13	None	A zero-day, with part of the attack chain still unpatched
OpenAI agent and Medicare Australia	Disclosed Sep 24	Agent ran the access	A lab's test agent reached a government statistics portal.

Readyset HA with ProxySQL and MySQL

ReadySet — Thu, 22 Oct 2026 00:00:00 +0000

A query cache stores the result of a SQL query and answers later identical queries from that stored copy instead of running them again. Readyset is a query cache for MySQL and PostgreSQL that works as a proxy: it speaks the database's wire protocol, so it can decide per query whether to answer from cache or pass the query through.

Speaking the wire protocol is what makes Readyset drop-in: anything that can connect to MySQL can connect to Readyset instead, with no driver or query change. Put two Readyset nodes behind ProxySQL and you have a cache tier that survives losing a node.

We wanted to know how small that change really is when the topology already exists. So we built the boring version of a production setup, a MySQL source with a replica and a pair of ProxySQL nodes in cluster mode in front of both, gave it a report query that costs 106 ms, and counted the steps needed to put a highly available (HA) cache behind that one query. It came to two docker runcommands and two INSERT statements in ProxySQL's admin interface. Nothing in the application changed, and neither did the schema or MySQL's configuration.

What a ProxySQL and MySQL topology looks like before Readyset

Seven machines in one availability zone, all c6i.large, which is 2 virtual central processing units (vCPUs) and 4 GiB of memory each. MySQL 8.0.46 on the source and on the replica, two ProxySQL 2.6.5 nodes in front of them, and the sakila sample database loaded on the source and replicated down.

Both ProxySQL nodes are configured the way most people configure one: hostgroup 10 is the writer, hostgroup 20 is the reader, writes go to the source, and a catch-all rule sends anything matching ^SELECT to the replica.

The two proxies run in ProxySQL's cluster mode, which makes them peers. Each lists the other in proxysql_servers, they share a cluster credential, and a configuration change applied to either one is pulled by the other within a few seconds. That is why adding Readyset below costs the same two statements it would cost with a single proxy.

Hostgroup	Backend	Purpose
10	MySQL source	all writes
20	MySQL replica	all reads

Everything in grey below was already running. Everything in green is what this post adds.

The two Readyset nodes and the hostgroup 30 routing are the whole change. Readyset connects to the replica as an ordinary SQL client, so there is no replication stream into it and nothing to configure on MySQL. The purple link is ProxySQL's cluster sync, which is why the routing has to be added on only one of the two proxies.

Which query is worth caching, and how ProxySQL tells you

ProxySQL already knows. It keeps a digest table of every query shape it has seen, with the total time spent on each, and the answer falls out of one query against the admin interface on port 6032.

SELECT hostgroup AS hg, digest, count_star AS calls,
       ROUND(sum_time/1000000,1) AS total_s,
       ROUND(sum_time/count_star/1000,1) AS avg_ms,
       substr(digest_text,1,50) AS query
  FROM stats_mysql_query_digest
 ORDER BY sum_time DESC LIMIT 5;


hg digest calls total_s avg_ms query
20 0xAD23E0866F6BDE4B 140 28.0 200.0 SELECT c.customer_id,c.first_name,c.last_name,ci.c
20 0xDDE78179CF5B1440 1 0.0 1.0 SELECT COUNT(*) FROM film
20 0xAC447120122130DE 1 0.0 0.0 SELECT COUNT(*) FROM actor
10 0xFE0D5031018F599A 2 0.0 0.0 SET NAMES utf8mb4

The ProxySQL admin interface is SQLite underneath, so substr() works andLEFT() does not. One shape accounts for all of the time. It is a customer leaderboard: the top 25 customers by lifetime value, each annotated with the film category they spend the most on.

SELECT c.customer_id, c.first_name, c.last_name, ci.city,
       SUM(p.amount) AS lifetime_value,
       COUNT(p.payment_id) AS payments,
       (SELECT cat.name
          FROM payment p2
          JOIN rental r2 ON r2.rental_id = p2.rental_id
          JOIN inventory i2 ON i2.inventory_id = r2.inventory_id
          JOIN film_category fc ON fc.film_id = i2.film_id
          JOIN category cat ON cat.category_id = fc.category_id
         WHERE p2.customer_id = c.customer_id
         GROUP BY cat.name
         ORDER BY SUM(p2.amount) DESC
         LIMIT 1) AS top_category
  FROM customer c
  JOIN address a ON a.address_id = c.address_id
  JOIN city ci ON ci.city_id = a.city_id
  JOIN payment p ON p.customer_id = c.customer_id
 GROUP BY c.customer_id, c.first_name, c.last_name, ci.city
 ORDER BY lifetime_value DESC
 LIMIT 25;

This query is not a straw man. EXPLAIN shows every join resolving through an index, and sakila is about 10 MB against a 2 GB buffer pool, so the whole working set is in memory and no read touches a disk. It costs 106 ms anyway, because the correlated subquery is a DEPENDENT SUBQUERY that MySQL evaluates once per customer. That is 599 executions of a five-table join, each building a temporary table and sorting it, on every single call.

Why not just rewrite the slow query

That is the first thing a database engineer asks, so we measured it. We rewrote the correlated subquery as a window function over a common table expression, which is the textbook fix, and ran both forms against the same replica.

Form	p50 latency	Queries per second
Original, with correlated subquery	106.360 ms	9.44
Rewritten with `ROW_NUMBER()` over a common table expression	88.595 ms	11.32

Single connection, 8 s warmup and 25 s measured, read directly against the MySQL replica.

The rewrite is worth 1.2x. The work being done is the same either way: aggregate 16,044 payments across a five-table join, then do the whole thing again for the next caller. Routing the query to Readyset is worth 149x on the same hardware, and it gets there by skipping the work rather than by doing it faster.

The minimal steps to add Readyset behind ProxySQL

Three commands total, and none of them touch MySQL, the application, or the second proxy.

First, run Readyset on two hosts. Each one is independent of the other, with no shared state and no clustering to configure. AUTO_CACHE=true is the whole configuration: it is shorthand for --cache-mode=shallow --query-caching=inrequestpath, which means every previously unseen SELECTbecomes a candidate for a cache that Readyset creates by itself, on the request path, the first time it sees the query.

docker run -d --name readyset --restart unless-stopped \
  -p 3307:3307 -p 6034:6034 \
  -e UPSTREAM_DB_URL=mysql://app:readyset@<replica-ip>:3306/sakila \
  -e LISTEN_ADDRESS=0.0.0.0:3307 \
  -e AUTO_CACHE=true \
  public.ecr.aws/readyset/readyset:latest-nightly

We pointed both nodes at the read replica rather than the source, so the queries Readyset runs upstream land on the machine that already serves reads.

Docker is here because it makes the deployment one command that a reader can run verbatim, which is what a demonstration needs. It is not the only option: the same adapter ships as .deb and .rpm packages for x86_64 and arm64, run under systemd and configured through /etc/readyset/readyset.conf. Both paths are covered atInstall Readyset Cache. The flags below are the same either way, as environment variables in Docker or as settings in the configuration file.

Both nodes were accepting connections about 45 seconds after docker runreturned, and that is the whole startup. In shallow mode Readyset does not replicate, which the log states plainly:

INFO readyset_server::controller::inner: Replication disabled; skipping snapshotting and replication

No replication user, no binary-log position, no snapshot of the dataset, no publication and no slot. Readyset connects to the upstream the same way any client does, runs the query on a miss, and keeps the result.

Second, tell ProxySQL the nodes exist, and point one query shape at them. This is the only change to the existing topology, and in cluster mode it is applied to one proxy rather than to each of them.

-- Hostgroup 30 is the new cache tier. The replica joins it at weight 1, which
-- makes it an automatic fallback: it takes 1 read in 2001 while Readyset is
-- healthy, and all of them when both Readyset nodes are gone.
INSERT INTO mysql_servers (hostgroup_id, hostname, port, weight, max_connections, comment)
VALUES (30, '<readyset-1-ip>', 3307, 1000, 500, 'readyset-1'),
       (30, '<readyset-2-ip>', 3307, 1000, 500, 'readyset-2'),
       (30, '<replica-ip>', 3306, 1, 500, 'mysql-replica-fallback');

-- Route exactly one query shape at the cache, by the digest ProxySQL reported.
INSERT INTO mysql_query_rules (rule_id, active, digest, destination_hostgroup, apply)
VALUES (50, 1, '0xAD23E0866F6BDE4B', 30, 1);

LOAD MYSQL SERVERS TO RUNTIME;
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
SAVE MYSQL QUERY RULES TO DISK;

Routing by digest rather than by table is what keeps the change small. The same tables keep serving hostgroup 20 for every other query. Only this one shape moves.

We ran that against proxysql-1 and nothing at all against proxysql-2. The second proxy picked the change up on its own in 3.7 seconds:

### proxysql-2 BEFORE, nothing applied to it directly
hostgroup 30 servers: 0
rule 50 present: 0

### applying the change to proxysql-1 ONLY
propagated to proxysql-2 in 3.7s, with no command run against it

### proxysql-2 AFTER
30 172.31.38.52 3306 1 mysql-replica-fallback
30 172.31.39.254 3307 1000 readyset-1
30 172.31.44.109 3307 1000 readyset-2
rule 50:
50 1 0xAD23E0866F6BDE4B 30

That is what cluster mode buys. Adding a cache tier to a pair of proxies is the same two statements as adding it to one, so the two proxies cannot drift into routing the same query differently.

One credential detail is easy to miss. Readyset authenticates incoming clients against its own upstream user, so the user ProxySQL uses for its backend connections has to be the same user that appears in UPSTREAM_DB_URL. A separate application user gets an access denied error at the Readyset connection.

What changed after routing one query to Readyset

Same driver, same ProxySQL endpoint, same query text. The only difference between the two halves of each pair is whether rule 50 is active.

Concurrency	MySQL p50	Readyset p50	MySQL q/s	Readyset q/s	Latency ratio
1	106.376 ms	0.716 ms	9.43	1291.93	149x
4	396.784 ms	2.401 ms	10.27	1463.33	165x
8	795.061 ms	5.398 ms	10.33	1301.70	147x

10 s warmup, 30 s measured, zero errors in every run. Latency ratio is p50 against p50.

The Readyset bars are drawn at a 3 pixel minimum so they are visible at all; at this scale their true widths are half a pixel. These are 2 vCPU demo machines and one query, so read the shape rather than the absolute numbers.

The rows come back identical. We compared the full result set and every field of every column definition between the cached path and the replica read directly: 25 rows, 7 columns, byte for byte the same.

How to confirm Readyset served the reads

A cache that exists is not a cache that is being used, and the failure mode looks like success: correct rows at a plausible latency, quietly served by the database. So we checked three separate things.

ProxySQL answers the first two: is the rule firing, and where did the query actually go. Both come from the admin interface on port 6032.

-- is the routing rule matching, and how often
SELECT s.rule_id, s.hits, r.destination_hostgroup
  FROM stats_mysql_query_rules s
  JOIN runtime_mysql_query_rules r USING(rule_id)
 ORDER BY s.rule_id;

-- and which hostgroup actually served that query shape
SELECT hostgroup, digest, count_star
  FROM stats_mysql_query_digest
 WHERE digest = '0xAD23E0866F6BDE4B';

We sent 800 reads at proxysql-1 and 400 at proxysql-2, and each proxy counted only its own share:

--- proxysql-1 (drove 800) ---
hostgroup digest count_star
30 0xAD23E0866F6BDE4B 800

--- proxysql-2 (drove 400) ---
rule_id hits destination_hostgroup
50 400 30
100 1 20
hostgroup digest count_star
30 0xAD23E0866F6BDE4B 400

Both proxies send the digest to hostgroup 30, and rule 100, the pre-existing catch-all, still handles everything else. One caveat if you run this yourself:stats_mysql_query_rules is flushed asynchronously, so straight after a burst it can lag the digest table by a few seconds before the two agree.

That proves the query reached Readyset. It does not prove Readyset answered from cache rather than passing the query upstream, which is the failure that looks exactly like success. Readyset's own per-query counters settle it:

curl -s localhost:6034/metrics | grep readyset_shallow_shallow_result


--- readyset-1 ---
readyset_shallow_shallow_result_hit{...,query_id="q_d618b5595f3efeab"} 98347
readyset_shallow_shallow_result_miss{...,query_id="q_d618b5595f3efeab"} 5
--- readyset-2 ---
readyset_shallow_shallow_result_hit{...,query_id="q_d618b5595f3efeab"} 93984
readyset_shallow_shallow_result_miss{...,query_id="q_d618b5595f3efeab"} 5

Hits move with the traffic and misses stay in single digits. Both nodes built the same cache for the same query identifier on their own, and both carried roughly half the reads. A Readyset node whose hit counter is flat while queries flow through it is serving everything from the database, and this is the counter to alert on.

Then we measured the instrument itself. A bare SELECT 1 over the same path, from the same driver through the same ProxySQL, costs 0.280 ms at p50. That is the client library, two network hops and the proxy, and it is 39% of Readyset's 0.716 ms. Readyset's own contribution to the cached read is closer to 0.44 ms.

What happens when a Readyset node or a ProxySQL node dies

Two tiers can now lose a node, so we killed one on each.

We ran the query continuously with four clients and stopped the Readyset nodes underneath it, checking every second whether the application was still getting correct answers.

Event	What the client saw
`docker stop` on Readyset 1	three errored connections in the second it happened, then cached reads again from the survivor
`docker stop` on Readyset 2, both now gone	reads served by the replica through the weight 1 fallback
Throughout	no second passed without completed queries, and the top row of the report never changed

Losing one Readyset node did not show up in the latency series at all. The survivor absorbed the traffic and the application had no way to tell.

Then we did the same to a proxy, with the load running against proxysql-2 andproxysql-1 stopped underneath it.

	Queries per second	p50
Load on proxysql-2, both proxies up	1460	2.47 ms
Load on proxysql-2, proxysql-1 stopped	1454	2.40 ms

Zero errors, and no second without completed queries.

The client talking to the surviving proxy did not notice, which is what a second proxy is for. Cluster mode also covers the rebuild. We brought proxysql-1 back from an empty configuration, with its data volume deleted and --initial on the command line, and it pulled the whole Readyset routing from its peer without being told any of it.

hostgroup 30 on the rebuilt proxysql-1, which was never told about Readyset:
30 172.31.38.52 3306 1 mysql-replica-fallback
30 172.31.39.254 3307 1000 readyset-1
30 172.31.44.109 3307 1000 readyset-2
50 1 0xAD23E0866F6BDE4B 30

Losing both Readyset nodes fell through to the replica and the application kept working at the speed it had before Readyset existed. That is the useful property of the weighted fallback: the degraded mode is the system you already had, not an error page. The handful of errors across these runs were connections in flight when a container was killed, and a client with retry logic would have swallowed them.

We did not measure how much load a pair of Readyset nodes can take, so none of these figures is a capacity claim. Two 2 vCPU machines is a demonstration size, not a sizing exercise.

Where the Readyset and ProxySQL pattern applies

The topology has to be a proxy that can route by query shape, in front of at least one read query expensive enough that the round trip to Readyset is worth avoiding. On a query that already runs in 2 ms, none of this pays for itself, because the floor we measured is 0.342 ms of driver and network before Readyset does anything at all.

The two Readyset nodes are independent caches, not a cluster. There is no shared state between them and nothing to configure to pair them up, which is the opposite of the ProxySQL pair, where cluster mode is the whole point. ProxySQL spreads reads across both Readyset nodes and takes either one out of rotation on its own, and that is what makes the Readyset failover simple.

What kept the change small is that nothing in the application knew about it. The connection string still points at ProxySQL, and the query text, the schema and MySQL's configuration are all exactly what they were. Cluster mode kept it small in the other direction too: a second proxy did not mean a second copy of the work. One query moved from a hostgroup that costs 106 ms to a Readyset hostgroup that costs 0.716 ms, and the rest of the workload never noticed.

The documentation for shallow caching, the --auto-cache flag and the other installation methods is atInstall Readyset Cache.

Meet the RDST Agent

ReadySet — Wed, 14 Oct 2026 00:00:00 +0000

An always-on agent that catches every slow query on your PostgreSQL or MySQL database and gives you the exact fix. It runs on your computer.

Product Updates | Readyset team | October 14, 2026

When a query gets slow, a customer usually notices first. The RDST Agent is built to catch it before that. It's a free, always-on agent that runs on your computer, watches every query on your Postgres or MySQL database, and hands you the exact fix.

Teams with a DBA or a monitoring budget usually have tooling that watches for this. A lot of teams running Postgres or MySQL on RDS, Supabase, Neon or their own servers don't, so query performance tends to get checked after something breaks.

Today we're releasing the RDST Agent , a free, always-on agent that runs on your computer, catches every slow query on your database, and gives you the exact fix when something goes wrong.

Home: two databases, one thing that needs you, and everything the agent did today.

To show what that looks like, we'll follow one afternoon on shop-prod, the PostgreSQL database behind an online store.

It keeps a history of every query

When you turn on monitoring, RDST reads your database's query statistics every minute, from pg_stat_statements on PostgreSQL or performance_schema on MySQL. It builds a history for every query: how often it runs, how long it takes and how much of the database's time it uses. The last 48 hours stay minute by minute, and older readings roll up into hourly and daily summaries that reach back months.

On shop-prod, the query behind the store's order history page usually takes about 6 ms. At 2:05 PM a deploy adds a new "My orders" page, and that same query starts taking 184 ms. Within minutes it's using almost a third of the database's time.

shop-prod at 2:14 PM. Order history jumps after the deploy, and the agent sends a desktop notification.

It notices, and it knows what's worth your time

Every 5 minutes the agent compares each busy query against its own history. It looks for queries that got slower or busier, changed plans, got stuck or started waiting on locks.

Most of those changes don't deserve an interruption. Jev, Readyset's attention model, decides which ones do. Order history getting 30x slower clears the bar, so at 2:14 PM it lands in the Inbox under Act now and a notification shows up on the desktop. Smaller wobbles stay on the chart for when you go looking.

The Inbox item explains what changed and what to check, with the SQL for each step.

It does the analysis nobody has time for

Two minutes later, the agent has a deep analysis. It runs EXPLAIN ANALYZE on the query with a real customer_id sampled from live traffic, and the plan shows the problem right away. Postgres is reading all 2.4 million rows of orders to find one customer's 20 most recent orders. The fix is a composite index on customer_id and created_at.

New heavy queries get this treatment as they show up, and every night the agent writes a report for each database with what to fix first, along with checks for bloat, unused indexes, settings and replication.

The analysis scores the query, shows what the plan is doing, and names the index to add.

Actions: one list of changes worth making

Everything the agent learns feeds Actions , a ranked list of the changes worth making across your databases. The new index goes straight to the top of Do first , because it saves about 7 seconds of database time every minute.

Right below it is an index to drop. orders_status_idx hasn't been used in 30 days, and every one of the 220 writes a second to orders still has to maintain it. The agent weighs each index against how often its table gets written to, so it'll recommend removing dead weight as readily as adding what's missing. Each action comes with the SQL to run and the SQL to undo it, and you can copy it as a migration for Alembic, Prisma, Rails or Flyway.

Actions for both databases, ranked into Do first, Then and Later.

RDST never writes to your database. You ship the change the way you ship any other migration, and the agent checks whether it worked.

At 3:02 PM the new index shows up on shop-prod. The agent measures Order history before and after: 184 ms down to 3.8 ms, and from 31% of the database's time to 2%. The action closes as Verified.

Verified: the agent measured the query before and after the index went in.

Why it runs on your desktop

We could have started with a hosted service. We started on the desktop because it's the shortest path to the databases people actually care about.

Your database credentials stay in your operating system's keychain. The connection runs from your machine straight to your database, so there's nothing to install on your servers, and Readyset never needs network access to your database. It reaches whatever your machine can reach, including a local Docker container, a database behind your VPN, or a private instance through an SSH jump host. Query history lives in a local SQLite database on your computer.

There's a tradeoff. The agent only collects while your computer is awake, and right now it's built for one person. For teams that want an agent running around the clock on their own infrastructure, we're working out a cloud version for enterprise teams. If that's you, tell us what you'd need at hello@readyset.io.

What gets sent to AI

Collecting stats, keeping history, running health checks and doing the arithmetic in reports all happen on your machine with no model involved. Two things go out.

Deep analyses and reports run on Claude Haiku from Anthropic. We don't send anything to foreign models. A request carries the query, its execution plan and the schema of the tables it touches, stripped of your data: no table contents, no result rows and no credentials. Anthropic doesn't train on API data. If you'd rather use your own Anthropic key, analysis goes straight from your machine to Anthropic.

Jev sees normalized query text along with table and index statistics, which is what it needs to decide what's worth your attention.

Every AI call the agent makes is listed on the Agent activity page, with what it did and when. The privacy docs cover the rest.

Agent activity: every check, analysis and verification from that Tuesday.

Try it

RDST is free and open source under Apache 2.0. It supports PostgreSQL 13+ and MySQL 8.0+ and runs on macOS (Apple Silicon), Windows and Linux. There's a demo database built in if you want to watch the agent work before you point it at your own.

Download RDST

Read the docs | RDST on GitHub

We'd love to hear what it finds on your database, and what it gets wrong. Come tell us in the Readyset Slack.

What Is a Wire-Compatible SQL Caching Proxy?

ReadySet — Thu, 08 Oct 2026 00:00:00 +0000

A wire-compatible SQL caching proxy sits between your application and your database, speaking the same protocol the database speaks. Because of this, your app can connect to the proxy instead of the database without any code changes, just swap the hostname or port.

The idea is simple. Right now, every query goes straight to the database:

With a caching proxy in front, the first time a query runs, it goes to the database as usual and the result gets cached:

The next time that same query runs, the proxy can skip the database entirely and answer from cache.

This cuts down on database load: fewer round trips, less query execution, and lower CPU and I/O usage, especially for read-heavy workloads where the same queries run over and over.

The tricky part is that caching SQL isn't as simple as storing a query string and its result. The proxy has to figure out when two queries are really asking for the same thing, know when cached data has gone stale and needs to be refreshed, and handle things like transactions, prepared statements, and session state correctly, all while staying invisible to the application.

In short: the goal is to make the database faster without the application ever knowing a cache is there.

How is this different from Redis or application-level caching?

The short version: Redis and application-level caching put the caching decisions in your code. A wire-compatible SQL caching proxy puts them in a separate layer, so your application doesn't have to think about caching at all.

How Redis-style caching works. Your application talks to two systems and has to coordinate between them:

Your code has to spell out the caching logic itself:

user = redis.get("user:123")
if user is None:
    user = database.query("SELECT * FROM users WHERE id = 123")
    redis.set("user:123", user)

That means your application now owns a lot of extra work: deciding on cache keys, converting objects to and from a storable format, setting expiration times, invalidating stale entries, handling cache misses, avoiding the "stampede" problem where many requests miss the cache at once and all hit the database together, and deciding upfront which queries are even worth caching. Redis is a general-purpose store, it doesn't know anything about SQL or your database schema. You decide what goes in it, which gives you a lot of control, but all of that logic lives in your application.

How a wire-compatible SQL proxy works.

Your application just sends its normal SQL, exactly as before:

SELECT id, name, email FROM users WHERE id = 123;

The proxy recognizes the query, checks whether it already has a valid and fresh cached answer, and returns it if so, otherwise it goes to the database like normal and caches the result on the way back. Your application never sees a difference and never has to check whether a result came from cache or not.

The core difference, in one line: Redis caches whatever your application explicitly tells it to; a SQL caching proxy caches query results automatically, with no caching API involved, the database connection itself just gets faster.

They're not competitors. A SQL caching proxy doesn't replace Redis, they solve different problems and often work side by side. Redis is still the right fit for sessions, queues, rate limiting, and general application data. A SQL caching proxy takes over one specific job: making repeated database queries faster, without your code managing any of it.

How is this different from a plain database caching proxy?

They're closely related, a wire-compatible SQL caching proxy is really just a stricter, more transparent version of a database caching proxy. The difference comes down to one thing: how convincingly it impersonates the real database.

	Regular caching proxy	Wire-compatible SQL caching proxy
Protocol	Its own separate API	The database's native wire protocol
Driver / client library	Often a different one	Same driver, unchanged
Connection string	Points at the caching API	Same connection string as before
Code changes required	Special calls (`cache.get(...)`), rewritten queries	None
Architecture	Application → Caching API → Database	Application → Proxy → Database
App's awareness of the cache	Knows it's there, cache logic lives in the codebase	None, has no idea it's not talking to the real database
What actually happens behind the scenes	Reads the query, checks for a cached result, returns it if valid and fresh, otherwise queries the database and caches the result	Same steps, but invisibly, the app just sees a normal query and a normal result

A closer look with MySQL

MySQL is one of the databases this kind of proxy typically supports, alongside PostgreSQL. The idea works exactly the same way, the proxy just needs to speak MySQL's specific wire protocol.

When a MySQL client connects, the server speaks first: it sends a handshake packet with a protocol version, server version string, and an authentication challenge (a random "salt"). The client responds with its username, a hashed password computed using that salt, its character set, and various capability flags. A wire-compatible proxy has to generate and validate this exact exchange, including MySQL's specific authentication plugins (mysql_native_password, caching_sha2_password, and others), so that any standard driver, mysql2 for Node, PyMySQL or mysqlclient for Python, Connector/J for Java, completes its handshake without ever suspecting it isn't talking to real MySQL.

MySQL clients also don't only send raw query text, the protocol defines command types like COM_QUERY for plain queries and COM_STMT_PREPARE/COM_STMT_EXECUTE for prepared statements, which most ORMs and drivers use by default. A proxy that only understood COM_QUERY would break the moment an application used prepared statements, so it needs to track prepared statement handles per connection and cache based on the query template plus its bound parameters, not just the raw bytes sent over the wire.

Results come back as a sequence of packets too, column definitions, then row data, then a closing packet, and the proxy has to reconstruct all of this exactly as MySQL would, matching data types and encodings so the driver doesn't choke on it. On top of that, MySQL connections carry session state (the current database, session variables, isolation level, autocommit mode) and support transactions, so the proxy has to track that state and be careful not to serve cached data where it would break consistency, such as inside an open transaction.

Because all of this is MySQL-specific plumbing, a proxy has to implement it separately from whatever it does for PostgreSQL, which has its own different wire protocol and message framing entirely. Products like ProxySQL, Vitess, and Readyset are examples of tools that do this kind of work for MySQL (some, including Readyset, support both MySQL and PostgreSQL by implementing both protocols side by side). Being "wire-compatible with MySQL" is a specific, real engineering claim: the proxy correctly implements MySQL's handshake, its authentication plugins, its command protocol, its result encoding, and enough of its session and transaction semantics that a MySQL driver, and the application built on top of it, genuinely cannot tell it isn't talking to MySQL itself.

What changes in your application code?

This is where a wire-compatible proxy becomes particularly interesting. With Redis-style caching, adding a cache usually means rewriting the code that touches your data. Your simple query:

result = db.execute("SELECT * FROM products WHERE category = 'laptops'")

turns into something with two paths to think about:

result = redis.get("products:laptops")

if result is None:
    result = db.execute("SELECT * FROM products WHERE category = 'laptops'")
    redis.set("products:laptops", result)

Now every developer touching this code has to understand both the cache-hit path and the cache-miss path.

With a wire-compatible proxy, your code doesn't change at all:

result = db.execute("SELECT * FROM products WHERE category = 'laptops'")

The proxy silently takes on the hit-or-miss decision, unnoticed by anything above it, answering directly on a cache hit and asking the database then caching the result on a miss.

Usually, the only real change is where your application points its connection. For a Postgres app, instead of:

postgres://app:password@database:5432/shop

it connects to:

postgres://app:password@proxy:5432/shop

The same is true for MySQL. Instead of:

mysql://app:password@database:3306/shop

the application connects to:

mysql://app:password@proxy:3306/shop

That's it. If your app uses mysql2 in Node, PyMySQL in Python, or Connector/J in Java, none of that code changes, you're not swapping libraries or adding a cache client, just pointing the same driver at a different host and port. Your ORM keeps generating the same queries it always did, completely unaware that a proxy is now answering some of them itself.

Same driver, same SQL, same ORM, same data access code; nothing in the application layer needs to change.

That said, "no code changes" doesn't mean "no setup at all." Rolling this out in production still usually involves some work: pointing things at the right connection endpoint, adjusting infrastructure, deciding which queries should be cached and for how long, thinking through how the cache stays consistent with the database, and setting up monitoring around it.

So the more accurate claim is: wire compatibility doesn't eliminate configuration, it eliminates the need to rewrite application code, because the proxy looks exactly like the database to everything talking to it. That's what "drop-in" should actually mean.

How Readyset works as a wire-compatible proxy

Readyset is a real-world example of everything above. It sits directly in the path between your application and your database, rather than off to the side the way Redis does.

Your app keeps sending normal SQL queries and getting normal query results back, it has no idea Readyset is even there. Meanwhile, Readyset watches the database's replication stream (its binlog, in MySQL's case) to learn about every write as it happens, so it always knows when its cached answers need updating.

Reads and writes travel different paths. Writes always go straight to the real database, they have to land in the source of truth. Reads are where Readyset earns its keep: if the answer's already cached, it hands it back instantly, no round trip, no query execution, nothing asked of the database at all.

This shows two common ways to set it up. On the left, your application talks to Readyset directly for anything that might be cached, and talks to the database directly for writes or queries Readyset hasn't cached. On the right, a query router sits in front of both and decides where each query should go, so the application doesn't even need to know Readyset exists as a separate destination. Either way, a normal read replica can still exist alongside Readyset, they're solving different problems: a read replica spreads out database load, while Readyset skips hitting the database at all for the queries it already knows the answer to.

This is a step up from a typical read-replica setup. Many teams already scale reads with something like this:

In this setup, HAProxy operates at Layer 4, it just forwards TCP connections to whichever backend a pre-configured port or pool points to, without ever reading what's inside them. It can split traffic toward a writable primary and a read-only replica, but only because the application (or its connection config) already decided which port to use; HAProxy itself has no idea whether a given connection is carrying a SELECT or an INSERT. And either way, every read that reaches the replica still has to run as a full query against a real database. Readyset replaces that pattern with something smarter: because it actually reads and understands the SQL passing through it, it can answer many reads without touching a database at all, not just route them to one.

What actually happens inside Readyset. This is the part that makes it more than a simple cache:

Readyset builds a small internal pipeline for each query it's asked to cache. Changes to the underlying tables (the "base table nodes") flow in from the database, pass through a chain of "SQL operator nodes" that mirror the actual joins, filters, and aggregations your query performs, and land in a "reader node" that holds the ready-to-serve result. When a row in the database changes, only the affected part of this pipeline needs to redo its work, not the whole query from scratch. This pattern is known as incremental view maintenance, and it's why Readyset is better described as a live, self-updating computation rather than a store you fill and empty by hand.

Conclusion: caching, moved to the database wire

The idea behind a wire-compatible SQL caching proxy comes down to one simple move: instead of every application building its own caching logic, you put a proxy between the app and the database that speaks the same protocol, understands the SQL flowing through it, and transparently answers what it can from cache.

That one change gets you a few things at once. Your existing queries, drivers, and ORM code mostly stay untouched. Your app never has to check a cache or invalidate one; it just sends SQL like normal. Because the proxy actually understands queries and the data behind them, it can keep answers correct as things change, not just guess with a timer. And your database itself sees less repeated work, since the proxy is absorbing traffic it would otherwise have to redo.

This is genuinely different from something like Redis. Redis gives you full control over what you cache, but you have to build and maintain that logic yourself. A wire-compatible proxy takes on that job itself, sitting closer to the database, so caching becomes something that just happens rather than something your team maintains.

A plain TCP load balancer like HAProxy can't do this split on its own; it just forwards connections without ever reading what's inside them, so it has no way to tell a cached-eligible read apart from a write. The split only works because the proxy sitting in this position actually speaks SQL and reads every query:

The bigger point is simple: don't make every team solve database caching on their own. Put that intelligence in the connection layer once, in a proxy that actually understands SQL, not just one that forwards bytes, and let it quietly make things faster for every application behind it. As more systems lean on read-heavy, increasingly complex queries, that's a real advantage, not just quicker responses, but a way to speed things up without asking developers to rethink how their code talks to the database in the first place.

Caching doesn't have to live in your application anymore. It can live in the connection itself.

See deep caching and the command reference for how a cached result stays correct as your data changes. Run rdst analyze to find out which of your own queries are candidates before you write a line of code.

Install RDST

September Product Update 2026

ReadySet — Thu, 01 Oct 2026 00:00:00 +0000

September was a packed month at Readyset, especially for RDST, and we're excited to be sharing the full release update with you.

RDST Is Now Apache 2 Licensed and Includes Unlimited Free Inferencing

We launched two big changes to RDST this month. First, it's now Apache 2 licensed. Use it, fork it, build on it, ship it inside your own tooling.

Second, hosted inference is on us for anyone signed in with a Readyset account. This means no API key required and no trial token limits. The default allowance covers hundreds of real questions a month per user, and if you need more, just reach out and we'll bump your allowance. Inference routes through OpenRouter across four US providers with automatic failover, so a single provider outage doesn't take RDST down with it.

More details here.

A Single Readyset Node Now Serves 4.3M Queries/Second

In our latest benchmark, Readyset reached 4.3 million queries per second on a single node, 6.4x the previous release's peak throughput on exactly the same hardware.

The biggest improvement came from distributing connections across multiple Tokio runtimes, allowing Readyset to use CPU capacity that previously sat idle. Alongside a set of profiling-driven improvements that together cut CPU cost per query from 45.7μs to 21.7μs.

Latency improved too. At 2,240 connections, throughput rose from 689,186 QPS to 4,111,367 QPS while p95 latency fell from 5.18ms to 0.75ms.

Read the full benchmark here.

Product Updates

Passwords Redacted in Logs: The adapter and server no longer write upstream, CDC, or client passwords to the log in clear text on startup. Passwords now appear as <redacted>.
Transient Errors Now Signal Retry-Safe: Readyset returns dialect-specific transient error codes on transient failures, giving clients and proxies a signal that the query is safe to retry automatically. Code 1317 (query interrupted) for MySQL and 55000 (database object not in prerequisite state) for PostgreSQL. Schema generation mismatch errors are reported as transient as well.
Correct Row Comparison Behavior in MySQL: A batch of fixes to row comparison behavior under MySQL. Row comparisons that were losing their predicate (widening the query to the whole table) are fixed. Comparisons between a number and a numeric string now resolve correctly instead of as unequal. A NULL inside a row now compares correctly instead of as an ordinary value. Prepared row comparisons are also no longer advertised to the client as taking no parameters.
PostgreSQL Cache Correctness Fixes: Named prepared statements filling a shallow cache no longer return binary-encoded values to clients that requested text format. bytea values are now encoded and decoded in the correct format. Prepared statements planned for a shallow cache that was later dropped now proxy upstream until the cache is recreated, instead of returning an error.
Copy-Paste-Ready EXPLAIN CACHES: EXPLAIN CACHES now prefixes each CREATE SHALLOW CACHE statement with USE <db>; for MySQL or SET search_path = <schema>; for PostgreSQL, and renders query placeholders in valid positions. That makes the output copy-paste-ready to recreate shallow caches across multiple databases or schemas.
Shallow Caches Persist Across Restarts: Shallow caches created via --auto-cache, CREATE CACHE hints, or CREATE CACHE FROM <query id> (from SHOW PROXIED QUERIES) are now correctly recreated when Readyset restarts, instead of being lost.
Caching Reliability Fixes: A batch of caching reliability fixes. Sessions using different collations now get separate shallow-cache entries so sorting stays correct. The ACL probe no longer incorrectly disables shallow caches when Readyset's parameterization differs from valid placeholder positions on the upstream. CREATE CACHE no longer crashes on queries with a very large LIMIT, and a race where an adapter reconnecting during DDL could briefly use an outdated schema, causing CREATE CACHE to fail, is fixed.

Plus 9 additional fixes and improvements. Check out the full release here.

New on the Blog & YouTube

Cache Invalidation for SQL Queries: How to Stop Writing It Yourself: Traditional caching means deciding what to invalidate after every write. Miss a dependency, and your cache can quietly serve stale results. This benchmark compares six caching strategies against the same workload to show what that mistake costs, and how incremental view maintenance avoids the invalidation problem entirely.

Upcoming Events

PostgreSQL Conference Europe 2026

We are heading to Valencia on October 20-23 for the 2026 PostgreSQL Conference in Europe. If you'll be there and want to talk caching, query performance, or anything else Postgres-related, we'd love to connect. Coffee's on us. Book a time here.

Full event details here.

Get Involved

Questions, bugs, ideas, or just want to say hi? Find us on Slack. Looking to contribute? Our newcomer issues are a good place to start.

What's New in RDST: Free Inference and an Apache 2.0 License

ReadySet — Tue, 29 Sep 2026 00:00:00 +0000

A few months ago we shipped RDST, our command-line tool for analyzing query performance on Postgres and MySQL databases. It ranks the queries running against your database by what they cost, and helps you understand and fix the ones slowing you down. It works with managed targets like RDS, Aurora, and Cloud SQL. More recently, we packed it into a full desktop app available on Mac, Windows, and Linux and added natural-language querying, database-level health analysis, and index and rewrite suggestions.

RDST finds the queries costing you the most time on your own database, walks through why they're slow using real execution plans, and hands you specific index changes, query rewrites, or cache candidates that have been checked against your actual schema. When you'd rather just ask a question of your data than write SQL by hand, RDST does that too, and validates the SQL against your schema before it runs.

We've now expanded RDST with two big upgrades.

Free inference, no API key required

Previously, running RDST meant bringing your own Anthropic key and paying for your own tokens. Now, if you sign in with a Readyset account, RDST runs on hosted inference we cover across every AI-powered part of the app.

The default per-account allowance covers hundreds of real questions a month, which is enough for most day-to-day use. If you need more, email us and we'll raise your limit.

Anyone running an LLM against their production database queries has a right to know exactly what leaves their machine. Transparency about this has been important to Readyset since day one. The RDST privacy notice covers what gets sent to the model, what stays local, and what happens on our side of the hosted inference. If you find a scenario where our notice on privacy or LLM usage falls short, let us know.

Apache 2.0

RDST was previously distributed under the Business Source License, which limited commercial redistribution. Under Apache 2.0, that limit is gone. Open source removes the licensing conversation from adoption, so teams evaluating RDST for internal tooling no longer need to route the decision through legal review. Fork it, ship it inside your own tooling, embed it in an internal developer platform, or vendor pieces of it into your own project. The source is on GitHub and contributions are open.

Try it

Install RDST

Have questions or want to talk to other RDST users? Join us on the Readyset community Slack. Full RDST documentation is available on our docs site.

Cache Invalidation for SQL Queries: How to stop writing it yourself

ReadySet — Mon, 21 Sep 2026 14:48:50 +0000

Cache invalidation is the problem of knowing when a cached query result has gone stale and needs replacing. A write changes one row in the database, and every cached answer derived from that row is now wrong. The work is finding those answers and dropping or refreshing them before the next read.

Say you have a read-heavy application and you've been asked to make reads faster. You put a cache in front of the database, the read path gets fast, and that invalidation work lands in your write path as a short list of rules. Here are the rules:

If a vote arrives, drop that story's key.
If a title changes, drop that story's key.
If an account is renamed, drop that user's key.

One rule per table. It reviews cleanly and it ships.

One of those three rules is wrong. The page it breaks keeps serving stale data until something unrelated evicts the entry.

We wanted to know what that mistake actually costs, and how the alternatives compare when they see identical writes. So we built a lab and measured six read paths against one workload.

Why one of those rules is wrong

Writing one of those rules wrong is easy. Here is the mistake in full, with the schema on the page. Three tables, quoted from Figure 2 of the Noria paper:

CREATE TABLE stories (id int, author int, title text, url text);
CREATE TABLE votes   (user int, story_id int);
CREATE TABLE users   (id int, username text);

The lab adds a primary key to each of the three tables.

A story page reads across all three. It needs a title from stories, a display name from users, and a count from votes, and all three collapse into a single cache key. So a cached result is not a copy of a row. It is an answer derived from rows in several tables, and no one of those tables can say which cached answers depend on it.

The code that writes knows which row it changed. The cache knows which key it holds. The mapping between the two lives in exactly one place, the text of the read query, and the read query sits nowhere near the write path:

SELECT s.id, s.title, u.username
  FROM stories s JOIN users u ON u.id = s.author
 WHERE s.id = ?;

The edge that matters is u.id = s.author. It says that changing a user dirties story pages. Nothing in the users table mentions a story, so the rename rule has no way to find the keys it just falsified. It drops a user key that this page never reads, and every story by that author keeps serving the old name.

Nothing catches this. A cache entry that should have been dropped and was not raises no error. It returns a plausible name, on the instances that happen to hold it, only for entries populated before that particular write. It will not reproduce on a laptop where the cache is empty, which is why this class of bug tends to be found by a user rather than by a test.

Almost nobody attempts precise invalidation

A 2023 survey by Ji, Zhou, Zhou and Wang analysed 20 Spring-cache web applications and surveyed more than 50 engineers. Of the cached methods they counted, 80.6% used a time to live or coarse-grained invalidation (dropping every cache entry associated with a table or namespace, rather than working out which specific entries a write affected), and only 10.4% attempted fine-grained invalidation.

Four out of five cached results in real projects do not attempt the mapping. They accept staleness instead. The authors' explanation of why:

All the aforementioned cases converge on a single fundamental challenge: the absence of a link between database updates and cache entries at the application level, making precise cache invalidation difficult to achieve.

Their examples are ordinary. One delete method issues 11 SQL statements across 9 tables, so no application-level rule can say what it dirtied. Another caches a query with range predicates, where deciding whether an update changes the result means evaluating the predicate.

Even teams who do this well find it hard. Meta's Polaris service exists to detect cache inconsistencies that reach production, and it moved TAO, the store behind Facebook's social graph, from 99.9999% to 99.99999999% consistency. Before Polaris, roughly one write in a million was silently wrong, and it took a purpose-built service to find out.

Cache invalidation strategies for SQL queries

Four strategies are in common use:

Time to live. Do not track dependencies at all. Put an expiry on each cached result and re-read the query when it lapses. This is the most widely used strategy because it is the only one with no invalidation code, and the trade is that the cache is correct within N seconds, and you chose N. A TTL cache also never learns that anything changed, so it re-reads on a schedule whether the underlying rows moved or not.

Manual cache keys, the Redis model. Store each result under a key the application chooses and delete those keys from the write path. Precise in principle. The cost is that the write path has to invert the read query by hand, and a missed edge is silent.

Event-driven invalidation. Read the database change stream, the MySQL binlog or the Postgres write-ahead log, and invalidate from it. Moving the trigger out of the application removes the race between a write and its invalidation, which is a real gain. The mapping stays. The team still writes and maintains the code that turns a changed row into the cache keys it affects, now in a stream processor rather than in a write path.

Incremental view maintenance. Apply each change to the stored result instead of discarding it. There is no invalidation step to write, because nothing is deleted.

Strategy	Who writes the invalidation	When the cached result is wrong	Cost of a write
Time to live	Nobody	Up to the length of the window, after every write	None, but refreshes run on a clock whether or not anything changed
Manual cache keys	The application, per query	Until eviction, whenever the mapping misses an edge	The invalidation, plus a burst of misses behind it
Event-driven invalidation	The application, in a stream processor	Until the mapping is corrected	Stream processing, plus the burst of misses
Incremental view maintenance	Nobody	Only while the change propagates	Maintenance work inside the dataflow graph

The rest of this post measures the first, the second and the fourth against each other on one schema. One write workload.

How we measured it

The lab runs on the three tables declared above, stories, users and votes, seeded at the scale the Noria paper reports for production Lobsters: 10,000 users, 40,000 stories and 500,000 votes. Six read paths served the same story page under one write workload, and saw exactly the same writes. Readyset runs with its query sampler off throughout.

The six paths:

MySQL directly, no cache, as a control
Redis look-aside with the three-rule invalidator, whose rename rule drops a user key and leaves every story page by that author wrong
Redis look-aside with a corrected invalidator
Readyset shallow cache, fixed 10 s TTL with a 5 s refresh
Readyset shallow cache with adaptive refresh
Readyset deep cache, which maintains the result incrementally, a technique called incremental view maintenance and abbreviated IVM in the tables that follow

Reads have to be continuous, or the number measures the cache miss instead of the cache: burst-reading a TTL cache reports 12 ms staleness where continuous reading of the same cache reports seconds. The write interval also has to be jittered. With a fixed interval, two runs of an identical configuration produced 4,783 ms and 177 ms, both arithmetically correct and both meaningless, because the answer was set by the phase relationship between the write clock and the cache's refresh clock.

What the control is measuring

The control path has no cache, so it cannot be stale. It is there to measure the instrument.

The clock starts when the write commits and stops when a reader first sees the new value, so the control's number is whatever that detection costs. Readers issue one query and read back to back with no pause between reads, which puts the control at 0.19 ms, and each observation is bracketed to 0.28 ms by the read that caught it. Every number in this post is measured at that resolution.

Two corrections: the readers used to sleep 2 ms between reads, so a write landed uniformly inside a detection window and half that window showed up as staleness. And each poll ran both cached queries while inspecting only the vote count, paying for a query it never used. Removing the sleep and the spare query moved the control from 2.00 ms to 0.19 ms.

Staggering more reader threads, which looks like the obvious fix, does nothing. For N readers at interval T the aggregate grid is T/N and the read load is N/T. So grid spacing is one over the load, and four readers at 8 ms is the same grid as one reader at 2 ms. The lever is aggregate read rate. Taking the sleep out reaches a grid of one round trip with a single thread.

Does the cache ever become correct?

In ten trials we warmed every path, renamed an author, then read continuously for 45 seconds and recorded when each path first returned the new name.

Read path	Converged	Never converged
no cache (control)	10	0
look-aside, three-rule invalidator	0	10 of 10
look-aside, corrected invalidator	10	0
Readyset shallow, fixed refresh	10	0
Readyset shallow, adaptive refresh	10	0
Readyset deep (IVM)	10	0

Ten out of ten. Every other path recovers. The three-rule invalidator never did, and in production the entry would stay wrong until unrelated memory pressure evicted it. That makes the bug's lifetime a property of the Redis eviction policy rather than of anything in the application.

The fix is more expensive than it looks. The rename rule has to ask the database which stories that author wrote, because that is the only way to learn which keys were dirtied. That puts a SELECT in the write path, with a fan-out equal to the number of stories the author has written, which is unbounded and largest for exactly the accounts that matter most. It also writes the join down a second time, so adding a column to the cached page means finding every write path that can touch it, again, with nothing to signal a miss.

How stale each cache gets

A vote arrives and the count changes. This is the write path the three-rule invalidator handled correctly, so it is the fairest comparison. Three runs of sixty writes, medians across runs.

Read path	p50	p95	Excess over the uncached control, p50
no cache (control)	0.19 ms	0.40 ms	n/a, this is the control
look-aside, corrected invalidator	1.11 ms	1.57 ms	0.92 ms
Readyset shallow, fixed refresh	2.68 s	4.74 s	2.68 s
Readyset shallow, adaptive refresh	2.29 s	4.28 s	2.29 s
Readyset deep (IVM)	1.66 ms	2.17 ms	1.48 ms

60 writes per run, 3 runs, medians across runs. Readers poll back to back at about 3569 reads/sec, so the instrument brackets each observation to 0.28 ms.

The TTL caches sit between two and five seconds behind. That is what a TTL is. With a 5 s refresh and uniformly phased writes, half the reads land in the first half of a refresh period, so the theoretical p50 is 2.5 s. Measured 2.68 s. Adaptive refresh helped a little and it can't help much, because it moves each entry's period between 10% and 100% of the configured value, so a 5 s refresh has a floor of 500 ms.

The look-aside cache is marginally the freshest of the three. At 1.11 ms it is about half a millisecond ahead of incremental view maintenance at 1.66 ms. Two conditions are doing work behind that number: the query is cheap, and the write rate is one write every seven seconds. That ordering makes sense once you look at what each one does with a write. A look-aside cache deletes the entry and lets the next reader refetch, so what it serves next is whatever MySQL has at that instant. Incremental view maintenance has to carry the write through the binlog and the dataflow graph before the stored result changes, and on this schema that costs about 1.5 ms over an uncached read.

So on the write path a hand-written invalidator gets right, it wins by half a millisecond. A harness that shows otherwise is probably measuring itself.

The advantage lasts only while the query is cheap

The story-page probe query is two indexed point lookups. When the look-aside cache throws its entry away, refetching costs about a millisecond, which is why deleting and refetching looks free. A query like that is rarely worth caching. The reason to cache is that recomputing is expensive.

So the same measurement, on a query with no index to lean on:

SELECT user, COUNT(*) AS c FROM votes WHERE user = ? GROUP BY user;

votes is indexed on story_id, not on user, so this is a full scan of about 500,000 rows and takes roughly 35 ms on this machine. Twenty-five writes, same method:

Read path	Staleness p50	Staleness p95	One read, p50
no cache (control)	59 ms	102 ms	36.62 ms
look-aside, corrected invalidator	42 ms	51 ms	0.16 ms
Readyset deep (IVM)	1.48 ms	1.96 ms	0.23 ms

The ordering inverts, and the deep cache is now about 28 times fresher rather than half a millisecond behind.

Read the last column next to the first. Both caches answer a single read in a fraction of a millisecond, so both are doing their job as caches. Their staleness differs by a factor of 28 because they recover from a write differently. A look-aside cache recovers by recomputing, so its staleness can never be lower than what the query costs. Incremental view maintenance recovers by applying one delta to the stored result, so its cost is set by the size of the change rather than the size of the scan, and it did not move between the cheap query and this one.

The uncached control is the same story from the other side: at 59 ms it is not stale, it is just slow, and every one of those milliseconds is work the database repeats on every read.

The TTL cache, given its best shot

Comparing against a fixed refresh period alone would be unfair, so the lab also runs Readyset's shallow cache with ADAPTIVE. Each entry's refresh period then moves between 10% and 100% of the configured value. The cache hashes each refreshed result, shrinks the period when the value changed, and grows it when it did not.

Adaptive refresh did engage: across the three runs the vote-count entry recorded 197 refreshes that found a change against 199 that did not, an almost exactly even split. Adaptation has nothing to bite on in that case, because the shrink and the grow are the same size and cancel, and the staleness reflects it: 2.29 s against 2.68 s, an improvement of about 15%.

Plotted per write, the two time-based lanes wander over the same range. The maintained view sits three orders of magnitude below both, on every write rather than on average:

What an invalidation costs beyond the invalidation

Deleting a hot key produces one cache miss per reader in flight, all at the same instant, all issuing the query to the database the cache was supposed to protect.

We put 32 readers on one story and wrote to it once every ten seconds, counting with MySQL's own Com_select so the harness could not inflate the number.

Read path	SELECTs in the write second	In a quiet second	Increase
look-aside, corrected invalidator	66	2	33x
Readyset shallow, fixed refresh	2	2	none
Readyset shallow, adaptive refresh	2	2	none
Readyset deep (IVM)	no write-correlated increase		none

60 s per arm, one write every 10 s. Com_select is MySQL's own counter.

Sixty-six is 32 readers times the two queries a story page needs, plus the couple of background queries present in a quiet second. One vote produced thirty-three times the steady query rate, in one second, against the database the cache exists to shield.

This is what the look-aside cache's half-millisecond freshness advantage costs. It is fresher because it throws the entry away and asks MySQL again, and asking MySQL again is the expensive part. Making its connection handling realistic, which is what closed the gap on the staleness table, did not soften the burst. It made the burst arrive sooner.

Neither Readyset path shows a spike, for different reasons. The TTL cache never learns that the write happened, so nothing changes at write time. The deep cache learns immediately and updates the stored result in place, so there is no entry to refill and no reader to send upstream.

The write rate is what decides this

Everything measured so far ran at one write every seven seconds on the probe row, which is one invalidation per roughly thirty thousand reads. That is the regime where a look-aside cache is at its strongest, because a look-aside cache is only useful in the gap between one invalidation and the next.

So the last measurement holds the readers constant and sweeps the write rate. Sixteen readers on one row, arms run one at a time so Com_select attributes cleanly, and the look-aside arm keeps every advantage it had: the invalidation is still a function call in the writing thread, still one cache key, still no queue and no second cache to fan out to.

Writes/sec on the row	Design	Cache hit rate	SELECTs/sec reaching MySQL	Writes behind, p50	Writes behind, p95
0.1	look-aside, corrected invalidator	100.0%	5	0	0
0.1	Readyset shallow, fixed refresh	100.0%	2	0	1
0.1	Readyset deep (IVM)	100.0%	2	0	0
1	look-aside, corrected invalidator	99.9%	35	0	0
1	Readyset shallow, fixed refresh	100.0%	2	2	5
1	Readyset deep (IVM)	100.0%	2	0	0
5	look-aside, corrected invalidator	99.5%	163	0	0
5	Readyset shallow, fixed refresh	100.0%	2	11	23
5	Readyset deep (IVM)	100.0%	2	0	0
20	look-aside, corrected invalidator	97.9%	641	0	0
20	Readyset shallow, fixed refresh	100.0%	2	45	94
20	Readyset deep (IVM)	100.0%	2	0	0
50	look-aside, corrected invalidator	94.3%	1600	0	1
50	Readyset shallow, fixed refresh	100.0%	2	111	235
50	Readyset deep (IVM)	100.0%	2	0	1

30 s per point, arms run one at a time so Com_select attributes cleanly. The look-aside arm is deliberately at its best case: invalidation in the writing thread, one cache key, no queue and no fan-out.

The two panels are the two different bills a cache can be handed, and each design pays only one of them.

The left panel is what the database pays: how many SELECTs per second reach MySQL while a cache is in front of it. The right panel is what the reader pays: how many writes behind the cached answer is when someone reads it. Both axes are log scaled, so a straight rising line is a proportional increase, and lower is better on both. A genuinely free design would be a flat line near the bottom of each panel.

As the write rate climbs, only one of the three changes is about staleness.

The look-aside cache stays current and sends the bill to the database. Its upstream load goes from 5 SELECTs per second to 1,600, a 302-fold rise across the sweep, tracking write rate times reader count almost exactly: 50 writes times 16 readers times the two queries a rebuild needs is 1,600. It is still fresh at 50 writes per second. It is fresh because it is asking MySQL sixteen hundred times a second about a row whose answer changed fifty times.

Its hit rate over that same sweep goes from 99.99% to 94.27%, and the two readings of that pair disagree completely:

On the left is what a hit-rate dashboard shows: a 5.7 point drift, which on any monitoring page reads as a cache doing its job. On the right is the same 5.7 points expressed as the thing the database actually receives, and it is a rise from 1.6 misses per second to 799, a factor of five hundred. Each of those misses costs two upstream queries, which is exactly the 1,600 SELECTs per second in the table.

Hit rate is a ratio, and a database is not charged in ratios. At 94% and sixteen thousand reads per second, the 6% is 799 requests that have to be computed from scratch, every second, on top of the write traffic that caused them.

The TTL cache holds upstream load flat and pushes the cost onto the reader. Two SELECTs per second at every write rate, because it never learns that anything changed. What moves instead is how far behind it is: 2 writes at 1 per second, 11 at 5, 45 at 20, and 111 at 50, with a p95 of 235. A five second refresh window times fifty writes a second is what that number has to be.

The maintained view does not move on either axis. 100% hit rate, zero writes behind, and none of the application's reads reaching MySQL at any write rate. The two SELECTs per second in that column are SELECT VERSION() and a session variable read, issued by Readyset's own connection to the database. Neither touches a table. The write side is doing more work at 50 writes per second than at 0.1, but the work is one delta per write through a graph, and on this query it does not show up as either staleness or database load.

A hand-written look-aside cache really is a shade fresher than incremental view maintenance, and it stays that way as the workload gets busier. It buys that by turning every write into a burst of reads against the database the cache exists to protect, and the bill grows with your write rate and your reader count at the same time.

What incremental view maintenance is

Incremental view maintenance keeps the stored result of a query up to date by applying each change to that result, rather than recomputing the query or discarding the result. A write becomes a delta, the delta flows through the relational operators of the query, and the stored answer is rewritten in place. A COUNT node receives "one more vote for story 1" and emits "the count for story 1 went from 7 to 8". There is no invalidation step, because nothing is deleted.

Incremental view maintenance has decades of literature behind it, and memory is what stopped it replacing caches. A maintained view is the whole answer set, so materializing every query an application runs costs more memory than the database. Streaming systems capped that by windowing, keeping only recent records, which is useless for an application that has to serve a four-year-old story as fast as this morning's.

The 2018 result that changed the memory problem

In October 2018 a group at MIT CSAIL published Noria: dynamic, partially-stateful data-flow for high-performance web applications at the 13th USENIX Symposium on Operating Systems Design and Implementation, the peer-reviewed systems conference usually shortened to OSDI. Noria is a database backend that compiles an application's SQL queries into a dataflow graph and keeps every one of their results materialized and current as writes stream in.

The paper builds on incremental view maintenance rather than inventing it. Its contribution is partially stateful dataflow, the mechanism that makes maintaining every query affordable enough to replace a cache rather than sit beside one. Readyset is the production descendant of that work. The project's own history file records the lineage: the codebase "builds on the Noria project, an open-source research prototype built by a team of grad students, post-docs, professors, and research affiliates at the MIT Parallel and Distributed Operating Systems (PDOS) lab, of which ReadySet's founding team was a part."

Partially stateful dataflow works like this. Operators are allowed to be incomplete: an operator holds only the entries that have actually been read, and treats a missing entry as a hole to fill on demand. A read for an absent key issues an upquery, which travels backwards up the dataflow graph to the operators that can recompute that entry, and the response flows forward along the normal path to fill the hole. Under memory pressure an operator evicts an entry and sends an eviction notice downstream, so everything derived from it is dropped rather than left quietly out of date.

Memory therefore tracks the working set instead of the table. In the paper's Lobsters measurements, partial state cut the state that could not be evicted to 73 MB, against 789 MB for full materialization over 137 MB of base tables.

Our lab shows the same shape. Reading K distinct story pages and asking Readyset what it is holding, via readyset_reader_state_size_bytes:

Distinct story keys read	Deep cache state	Bytes per key	Share of base tables
0	0 KB	0	0.00%
100	45 KB	464	0.22%
1,000	453 KB	464	2.17%
5,000	2.2 MB	464	10.84%
20,000	8.9 MB	464	43.37%
40,000	17.7 MB	464	86.74%

40,000 stories exist. Base tables are 20.4 MB of data in MySQL. Metric: readyset_reader_state_size_bytes.

464 bytes per key, flat across three orders of magnitude, and nothing held for keys nobody asked for. Read a hundred story pages and the caches hold 45 KB against 20.4 MB of base tables. Read all 40,000 and they hold 17.7 MB, still under the base tables, which is the case partial state does nothing for because there is nothing partial about it any more.

The practical version: a deep cache is sized by the working set, the same rule already used for Redis.

How to cache expensive SQL queries automatically

A query is cached automatically when adding the cache needs no application change and keeping it correct needs none either. Readyset gives both. It speaks the MySQL and Postgres wire protocols, so the application connects with its existing driver, and a cache is one statement:

CREATE CACHE FROM
  SELECT s.id, s.title, u.username
    FROM stories s JOIN users u ON u.id = s.author WHERE s.id = 2;

The caching is automatic because the invalidation is automatic. Readyset keeps each cached result current with incremental view maintenance, driven by the MySQL binlog or the Postgres write-ahead log, so there is no invalidation step for the application to write. A caching layer that stores results and hands back an invalidation problem has automated the read path and left the write path alone. Teams comparing SQL query caching tools for MySQL usually weigh hit rates and latency, and the more useful question is what each tool requires in the write path.

The property to design around

Incremental view maintenance is eventually consistent. The Noria paper states the guarantee this way: if writes quiesce, all external views eventually hold results that are the same as if the queries had been executed directly against the base tables. Under two milliseconds is short, and it is still not zero and not a transaction, so a read-your-own-writes path belongs on the database rather than behind any cache, this one included.

Accepting that window is a design decision, and it is the same one already being made with a TTL, except that the window is milliseconds instead of seconds and it does not have to be chosen or tuned.

What this comes down to

The mapping from a write to the cached answers it falsified is a graph, and nothing in application code validates that graph. Four out of five projects in the survey reached the same conclusion and took the TTL, which trades correctness for a window.

Partial state is what makes replacing invalidation practical. On our schema it bought this: on a cheap query, a maintained view sat 1.66 ms behind the database and a correctly written look-aside cache beat it, at 1.11 ms, while a TTL cache sat 2.68 s behind. On a query expensive enough to be worth caching, the same look-aside cache sat 42 ms behind and the maintained view did not move from 1.48 ms, because one design recovers by recomputing and the other by applying a delta.

The look-aside cache also paid for its freshness on both queries with a burst of 66 queries into MySQL after every write. The maintained view produced no burst, needed no window chosen or tuned, and required no invalidation code, because in that design there is nothing to invalidate. The three-rule invalidator, meanwhile, is still serving the wrong author name.

For how the dataflow engine maintains a cached result, see deep caching and How Readyset Speeds Up Queries with Streaming Dataflow. For the TTL model and when it fits better, see shallow caching, and the CREATE CACHE reference for the statement itself.

How We Reached 4.3 Million QPS for MySQL and PostgreSQL workloads on a Single Readyset Node

ReadySet — Thu, 10 Sep 2026 13:50:24 +0000

A single Readyset node now serves 4.3 million queries per second, more than twice what we measured with PostgreSQL and almost three times what we measured with MySQL on the same server.

We got there by profiling the serving path, finding the bottlenecks, and measuring again. The full post walks through exactly what changed: how we located the contention in the Tokio runtime, swapped SipHash for ahash on the hot paths, fixed several costs that had been hidden, and kept profiling until CPU cost per query dropped from 45.7µs to 21.7µs. At full throughput, most of the CPU now goes into the kernel network stack rather than the cache lookup, which points to where the next ceiling is.

Compute keeps getting more expensive and AI workloads are competing for the same CPUs, memory, and networking your database depends on. Serving repeated reads from Readyset keeps that load off the database, so its CPU stays free for writes, cache misses, and the queries that actually need the execution engine, and you get more out of the hardware you already have.

Read the full article here.

August Product Update 2026

ReadySet — Tue, 01 Sep 2026 16:22:51 +0000

Our August product update is live. 🚀

We launched the Readyset Platform, a self-tuning query acceleration layer you can demo right in our rdst desktop app. Adaptive Cache shipped and is already dropping p95 staleness by 97% compared to a standard TTL cache. TopK hit GA. And we cut CPU load on shallow cache workloads by roughly 75%.

There's a lot more in the full update, including a roundup of recent content and two upcoming events in September to mark on your calendar.