Hacker News Reader

Comment by d_watt | Hacker News Reader

Interesting. What would you say the use case is for this, rather than setting up read replicas? Not having to maintain routing to the replicas on the application side?

View on HN

When you care about perf a lot more than consistency

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!)

You can read more about how it works here: https://docs.readyset.io/concepts/overview

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

https://people.csail.mit.edu/malte/pub/papers/2019-hotos-mul...

Reply on news.ycombinator.com