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.
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.
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.
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.
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.
Readyset