DEV Community: ReadySet

How Readyset Rewrites Your SQL: Subqueries in HAVING, ORDER BY, JOIN ON

ReadySet — Thu, 20 Aug 2026 14:09:21 +0000

Readyset's rewrite pipeline now handles subqueries in four new positions: HAVING, ORDER BY, INNER JOIN ON, and LEFT OUTER JOIN ON. Queries that previously fell back to the upstream database now compile and maintain incrementally.

BI tools, reporting queries, and hand-written SQL regularly put subqueries in these positions. All four rewrites build on the same underlying idea of moving the subquery to a position that existing decorrelation already handles.

LEFT OUTER JOIN ON required a different approach entirely, because the obvious move of placing the subquery predicate in WHERE silently drops rows the join was meant to preserve. The post works through what the correct solution looks like and why the mechanics of the dataflow model make it necessary.

Read the full article here.

Introducing Adaptive Cache for Dynamically Managing Freshness

ReadySet — Thu, 13 Aug 2026 14:08:23 +0000

Traditional caches give you the same tradeoff: pick one refresh interval, and it applies to everything. Stable data gets refreshed more than it needs to while volatile data sits stale longer than you'd like. Tune one, you compromise the other.

That's why we built Adaptive Cache, which is available today as part of the Readyset Platform. Adaptive Cache adjusts the refresh interval per cached result based on how frequently that result actually changes, with no manual tuning required.

In our testing, p95 staleness dropped 97% compared to a standard TTL cache, with only a 60% increase in upstream refresh load instead of the 490% increase you would need to achieve the same result by manually shrinking the interval.

This is a key step toward caching that's truly invisible, no tuning, no babysitting.

Read the full post here.

Your Database Bill Is Climbing Faster Than Your Traffic

ReadySet — Thu, 06 Aug 2026 13:00:00 +0000

Cloud infrastructure pricing is moving in a direction nobody wanted. DRAM contract prices rose 93% to 98% in a single quarter, and that cost is landing on database bills across the board, which means the instance you are running today is going to cost more over the next year.

The cost per query is a lever you can still move, and we ran the benchmark to show what that looks like in practice: Readyset in front of MySQL on the same hardware, 99.94% of reads served from cache, cost per million queries dropping from $1.36 to $0.0064, a gap that held under every projected price increase we modeled.

If you run a cloud database, here is the full analysis and reproducible benchmark.

July Product Update

ReadySet — Mon, 03 Aug 2026 17:45:14 +0000

Our July Product Update is Live!

We launched the Readyset Platform this month, combining QueryPilot, rdst, and new components into a self-tuning query acceleration layer. Now available as a desktop app so you can run and test it on your own workload. Freshness that tunes itself, eviction that can't be thrashed, built-in debugging. It’s a cache you can just leave on.

Khanh Tran, VP of Engineering at Hussle, put it well: "Our optimization has moved from low config to no config."

Plus, we cut CPU load on shallow cache workloads by 75%, shipped TopK as generally available, expanded Postgres cache coverage, and more. The full update covers our latest release, a roundup of our recent content, and details on our upcoming August 18 webinar, where you can see the Readyset Platform in action.

Read it here.

How the AI Buildout Is Repricing the Rest of Your Infrastructure

ReadySet — Thu, 30 Jul 2026 14:07:08 +0000

The biggest near-term cost of the AI boom is what the buildout is doing to the price of everything else you run. DRAM contract prices rose 90 to 95 percent in a single quarter, and memory-heavy infrastructure like databases is taking the hardest hit.

Our white paper How the AI Buildout Is Repricing the Rest of Your Infrastructure covers how AI demand is repricing ordinary compute and which changes pay for themselves at current prices.

Nobody wants a cache

ReadySet — Wed, 22 Jul 2026 14:10:54 +0000

Nobody wants a cache. What people want is for reads to be fast, and for that speed to stop costing them.

When reads get expensive, most teams have two options: scale up with bigger instances and read replicas, or build caching by hand and pay engineers to maintain it. Both can be serious spend, and both hold only until the next time traffic shifts.

Today we're launching the Readyset Platform. Caching now runs in your infrastructure and tunes itself as workloads change. It decides what's worth caching, adjusts freshness per query, and directs memory where it delivers the most return.

The result is smaller instances, fewer read replicas, and engineering time back on your roadmap instead of your cache. It's the cache you can leave on, and it will be better four months from now than it is today, at no additional cost to you.

Our CEO Gautam Gopinadhan wrote up the thinking behind it, where automatic caching goes wrong, and what we built to close those gaps.

TopK is now Generally Available

ReadySet — Thu, 16 Jul 2026 14:06:30 +0000

Leaderboards, activity feeds, top-rated products. Most applications have at least a few queries that ask for the best K rows out of a large set.

Readyset has always been able to cache those queries. With TopK, it now does so much more efficiently by storing only the top K rows per key instead of every matching row.

TopK is now generally available. The new approach reduces memory usage by several orders of magnitude, keeps more keys resident in cache, and eliminates post-processing overhead on every read.

No application changes. No new flags. If your cached queries have the right shape, Readyset starts using the TopK operator automatically when you upgrade.

The full post covers what changed, how the buffer tuning works, and when to touch the defaults.

Readyset Internals: The left-right pattern: lock-free cache

ReadySet — Mon, 13 Jul 2026 14:13:28 +0000

One of the questions we get asked most often: how does Readyset serve cached reads without ever taking a lock?

The answer is a pattern called left-right. Instead of making readers and writers compete over the same data, Readyset keeps two copies. Readers use one while writes happen on the other, then a single atomic pointer flip makes the updated data visible. Readers never wait on writes, and writes never block readers.

Full writeup with benchmarks and an honest look at the tradeoffs here.

June Product Update

ReadySet — Thu, 02 Jul 2026 17:43:49 +0000

We packed a lot into June!

We took the stage (and the exhibition floor) at Web Summit Rio, where Gautam Gopinadhan gave a talk on a question more teams are running into: AI is querying your database. Are you in control?

We also shipped new caching and reliability improvements, published new technical content on our MCP server and on caching Supabase with Readyset over IPv6, and more.

Catch up on everything from June!

The Real Cost of Read Replicas (and When They Stop Paying Off)

ReadySet — Wed, 01 Jul 2026 14:26:29 +0000

There is a reflex every engineering team develops once read traffic starts climbing: the primary is sweating, so you spin up another read replica.

It works, but it does not actually reduce the work being done. It spreads the same expensive queries across more copies of the same database, each one independently recomputing identical results. Costs keep climbing, replication large becomes another operational concern, and every replica adds more infrastructure to manage.

We wrote about where replicas earn their keep, where they stop paying off, and what it looked like when Lemit hit a hard ceiling at 13,000 reads per second on fully maxed out hardware before pushing past 109,000 QPS by caching repetitive reads instead of adding more replicas.

Caching Supabase with Readyset over IPv6: the AWS and Docker pieces that have to line up

ReadySet — Mon, 29 Jun 2026 14:06:26 +0000

Readyset has been a great solution for Supabase users to reduce read latency without changing application code.

With the introduction of Shallow Cache, we've made it easier than ever to get started with your Supabase project within minutes.

This guide walks you through the simple steps needed to get your AWS networking environment setup end-to-end with Supabase in the default IPv6 mode.

Your AI now speaks Readyset: announcing the MCP server

ReadySet — Mon, 22 Jun 2026 14:10:24 +0000

Your "copy SQL into a chat window, paste the result back" loop is over.

Readyset now supports MCP natively, which means Claude, Cursor, Windsurf, and any other MCP-aware agent can connect directly to your Readyset instance, inspect proxied queries, see what is cacheable, and create or drop caches without you having to do it by hand!

We shipped two transports because teams run databases in different ways. A stdio binary that runs on your laptop with the credentials you already have, and an embedded HTTP endpoint built into the Readyset server for shared agents, CI jobs, and multi-user setups with scoped, revocable tokens.

The decision to let an AI touch your database should belong to you. Both transports were built with that in mind.