marzoeva

Yes, co-founder. You can read our initial announcement below!

https://twitter.com/jonhoo/status/1511401461669720068 https://readyset.io/blog/introducing-readyset

We need either Consul or Zookeeper (for leader election). No dependency on Redis!

That part of the blog post refers to ReadySet having a SQL interface, rather than a key-value one.

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...

This is indeed our goal– we're most of the way there with SQL 92 and plan to continue to expand our query support over time!

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

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