September Product Update

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.