Hi! CEO of ReadySet here. You can think of ReadySet as being a cross between a traditional read replica and a custom caching layer (e.g. one you might build on top of Redis). With read replicas, you still rerun queries from scratch every time they're issued, which means you still have to think about things like query optimization. ReadySet caches frequently run queries in memory so you get super-fast query latencies on cache hits. Because of this, you can scale to much higher read throughputs without extra effort. This is especially useful for read-heavy applications (e.g. websites, certain types of dashboards, among others!)
How do you deal with security? In modern databases like MongoDB permissions are granular down to the field level.
The same query could produce wildly different result based on the user issuing them, and the caching somehow has to take that into account. Is that something you address?
Funnily enough, I wrote a paper on this topic when I was in grad school. It's not on our short-term roadmap at ReadySet, but this idea is certainly compatible with the underlying dataflow model. I'd love to hear more about what you had in mind here, shoot me an email at alana@readyset.io
We're tackling this problem at ReadySet. TLDR, ReadySet connects to your existing relational database and caches SQL query results at the edge based on the actual traffic patterns in those regions. Our goal is to augment rather than replace the database as the source of truth. You can sign up for our early access list here: https://readyset.io
https://twitter.com/jonhoo/status/1511401461669720068 https://readyset.io/blog/introducing-readyset