Caching Shouldn't Be a Part Time Job

As of today, Readyset can do it for you. It already identifies expensive queries and automatically caches them, but now the cache continuously re-evaluates which queries to cache, tunes TTL per query, and optimizes as queries and data change.

Automatic caching has earned a healthy degree of skepticism, and not without reason, because a cache that cannot distinguish "out of date" from "wrong" will eventually serve wrong data and do it quietly. Nothing errors, nothing pages anyone, and the report comes back from a customer rather than a dashboard.

That's the failure mode automatic caching has to design against. Here's what that looks like in practice:

• Freshness becomes a dial rather than a guess. A staleness ceiling gets set once, and nothing is served older than it. Underneath that ceiling, each query's refresh rate tunes itself to how quickly that query's data actually changes, so a products table that moves twice a day and a cart table that moves every few seconds stop sharing a single setting.
• Memory follows value rather than activity. Queries earn their place in the cache based on what they save, not just frequency. The cache keeps its memory focused where it has the greatest impact as workloads change.
• Expiry stops turning into a stampede. When a hot entry expires and a hundred identical requests arrive together, one goes to the database and the rest wait and share the result, so a refresh does not become a self-inflicted flood.

None of this is novel as an idea. It's the rule systems designers have held themselves to for decades, in the layers closest to hardware. A CPU has several caches. So does the memory controller, the OS page cache, the disk, the DNS resolver. Nobody invalidates any of them, and the reason nobody has to is that a cache may change how long an answer takes, but it may not change the answer. Database caching is one of the few places that rule still gets waived, and there's no good reason for it to stay that way.

Today's Readyset release brings those capabilities together into one platform. Readyset now continuously tunes freshness, manages memory, protects itself from thrashing, and resolves uncertainty toward the database, so it can be left running as workloads evolve. You don't have to take our word for it, you can see this in action in a few quick commands here.

🔍 What We're Watching in the Database Ecosystem

Running DuckDB as a MySQL Storage Engine

An experimental MySQL 9.7 build where marking a table ENGINE=DuckDB sends analytical queries to DuckDB's column store instead of InnoDB, same server, no second copy of the data. On TPC-H at scale factor 10, InnoDB timed out on 6 of 22 queries and spent 1,317 seconds on the rest, while the DuckDB tables finished all 22 in about 15 seconds.

AI-Generated Schemas Have the Same Problems Every Time

A consultant lists what he keeps finding when reviewing AI-generated schemas: no indexes past the primary key, no constraints, VARCHAR(255) for everything, money as FLOAT. The underlying point is that database design follows access patterns and the model only sees entities. The comments push back hard, arguing it's a prompting problem and that humans have shipped these same schemas for decades, which makes for an interesting thread.

In Case You Missed It

For the story behind this week's launch, our CEO Gautam Gopinadhan argues that nobody wants a cache: your laptop is full of them and you've never invalidated a single one, because a cache that changes the answer is a broken cache. Database caching is the last place we still do that work by hand.

Readyset Internals: The left-right pattern: lock-free cache: Most caches put a lock around their hot data, and once traffic is real, everyone waits on everyone else. Vinicius explains how Readyset skips that entirely, keeping two copies of the map so readers never wait on a writer and a new batch goes live with one atomic pointer flip, measured at about 1.2 nanoseconds.

Know a database aficionado who'd appreciate this? Forward it their way.