Why Cache Maintenance Is Moving Into the Database

Last week we looked at one of the harder problems in caching, which is keeping a cached result correct once the underlying data changes. This week it's worth asking a related question about where the responsibility for that correctness should actually live.

Traditionally, that responsibility has sat with the application. Developers decide what to cache, how long to keep it, and when an entry should be refreshed or thrown out. It works, but it turns correctness into a manual part time job.

That arrangement is starting to change. As applications grow more complex, more teams are looking for a better method. Instead of treating cache correctness as application logic to maintain by hand, they're looking to move that responsibility down into the data layer, where cached results are kept in sync automatically as the underlying data changes.

Oracle's release of True Cache, including the free edition, is a clear marker of that change. Rather than relying on the application to manage invalidation, True Cache keeps itself synchronized with the primary by continuously applying committed changes. Oracle is also upfront about the tradeoff: a cache maintained asynchronously can briefly lag behind the primary.

What's interesting here isn't the implementation so much as what the decision signals. Oracle didn't invent this architectural approach, but its investment reinforces that automatic cache maintenance is becoming a capability more teams expect from their database infrastructure.

MySQL and Postgres teams have had access to this approach for a while now. Readyset sits in front of the database and maintains cached query results automatically from the replication stream, so results stay correct as data changes, with no cache keys, TTLs, or hand-written invalidation logic. Oracle is bringing that model into its own ecosystem. Readyset already delivers that same architectural approach to MySQL and PostgreSQL.

🔍 What We're Watching in the Database Ecosystem

See What Your Database Is Doing Right Now

PlanetScale introduced a new way to inspect live database connections from the CLI, including a blocker tree that surfaces the single transaction holding everyone else up. The broader takeaway is that real-time visibility into what a production database is doing, as it's doing it, is becoming a more important part of operating database infrastructure.

Postgres Storage That Tiers Itself, and Stays Writable

pgEdge's ColdFront moves older rows out of a growing Postgres table automatically, into cheaper object storage in Apache Iceberg while the application keeps reading and writing through the same table name. The part that stands out is the cold tier stays writable, so a GDPR deletion against years-old archived data is one SQL statement rather than a restore-delete-rearchive project.

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