BEbenoitg·Aug 25, 2025Submission
Readyset is a MySQL and Postgres wire-compatible caching layer
2 points · Open discussionreadysettech
readyset
Rust2022–2025
readysettech / readyset
readyset
Readyset is a MySQL and Postgres wire-compatible caching layer that sits in front of existing databases to speed up queries and horizontally scale read throughput. Under the hood, ReadySet caches the results of cached select statements and incrementally updates these results over time as the underlying data changes.
8Distinct people
9Mentions
0Explicit recommenders
5.3KGitHub stars
What to know before exploring
What it is
Readyset is a MySQL and Postgres wire-compatible caching layer that sits in front of existing databases to speed up queries and horizontally scale read throughput. Under the hood, ReadySet caches the results of cached select statements and incrementally updates these results over time as the underlying data changes.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year9 dated mentions
Observed mentions: 2022-06-16 17:14:23 UTC to 2025-08-25 08:54:49 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
9 sourcesI just wanted to give a high five for having Jepsen tests for this: https://github.com/readysettech/readyset/tree/stable-240117/...
In Readyset: A MySQL and Postgres wire-compatible caching layerIn the Microsoft SQL Server space, several of these vendors have come and gone. My clients have been burned badly by 'em, so a few quick lessons learned:
Be aware that there are hundreds of open issues[0] and dozens of pull requests [1], some of which involve clients being unable to connect or not supporting all components of the SQL language. Just because your database supports something, doesn't mean your caching layer will.
It gets really ugly when a new version of your database comes out, with brand new features and language enhancements, and the caching layer doesn't support it. It may take months, or in some cases years, before the caching layer is feature-complete with the underlying database. If you want to use some of those language enhancements, then your app may have to maintain two connection strings - one for the caching laye
Read the rest
r, and one for direct database queries that the caching layer doesn't support.
Your support teams need to learn how to diagnose problems with the caching layer. For example, this issue [2] talks about the level of work involved with understanding why newly inserted data isn't showing up in selects.
I hope they succeed and deliver the concept, because it's one of the holy grails of databases.
[0]: https://github.com/readysettech/readyset/issues
[1]: https://github.com/readysettech/readyset/pulls
[2]: https://github.com/readysettech/readyset/issues/39
Readyset: A MySQL and Postgres wire-compatible caching layer
164 points · Open discussionThis example is a great use case for partial incremental view maintenance systems like ReadySet: you automatically get something like the “prepopulating the cache” section (toward the end of the blog) while only caching the data the application is using, and avoiding the need to manually implement any sort of invalidation logic.
(Disclaimer: I used to work for them, but don’t anymore. It’s all available for free on GitHub though for anyone interested: https://github.com/readysettech/readyset)
In Fine-grained caching strategies of dynamic queries:wave: Author of the paper this work is based on here.
I'm so excited to see dynamic, partially-stateful data-flow for incremental materialized view maintenance becoming more wide-spread! I continue to think it's a _great_ idea, and the speed-ups (and complexity reduction) it can yield are pretty immense, so seeing more folks building on the idea makes me very happy.
The PlanetScale blog post references my original "Noria" OSDI paper (https://pdos.csail.mit.edu/papers/noria:osdi18.pdf), but I'd actually recommend my PhD thesis instead (https://jon.thesquareplanet.com/papers/phd-thesis.pdf), as it goes much deeper about some of the technical challenges and solutions involved. It also has a chapter (Appendix A) that covers how it all works by analogy, which the less-technical among the audience may appreciate :) A recording of my thesis def
Read the rest
ense on this, which may be more digestible than the thesis itself, is also online at https://www.youtube.com/watch?v=GctxvSPIfr8, as well as a shorter talk from a few years earlier at https://www.youtube.com/watch?v=s19G6n0UjsM. And the Noria research prototype (written in Rust) is on GitHub: https://github.com/mit-pdos/noria.
As others have already mentioned in the comments, I co-founded ReadySet (https://readyset.io/) shortly after graduating specifically to build off of Noria, and they're doing amazing work to provide these kinds of speed-ups for general-purpose relational databases. If you're using one of those, it's worth giving ReadySet a look to get these kinds of speedups there! It's also source-available @ https://github.com/readysettech/readyset if you're curious.
BSL <https://github.com/readysettech/readyset/blob/main/LICENSE> so they're serious about the "freely available" part I guess
In ReadySet Core: next-generation SQL caching, freely availableHey, PM @ ReadySet - fair points, and thanks for checking us out.
We've been in pretty heavy development and have been heads down on getting ReadySet into your hands as quickly as we could. We'll be doing a major documentation pass soon which will have more info about clustering, etc.
There's also a bit more detail in our development guide - see https://github.com/readysettech/readyset/blob/main/developme...
In ReadySet Core: next-generation SQL caching, freely availableGitHub repo : https://github.com/readysettech/readyset
In ReadySet Core: next-generation SQL caching, freely available