Readyset: A MySQL and Postgres wire-compatible caching layer
1–10 of 71 posts
Re: Readyset: A MySQL and Postgres wire-compatible caching layer
#2Anyone successfully using? There are a few other services out there like PolyScale.
It will be interesting to see if any of these introduce some form of write support over time
Re: Readyset: A MySQL and Postgres wire-compatible caching layer
#3This is one of the deepest deep tech startups I've seen in a long time.
I had the pleasure to meet some of the folks at RustConf in Portland.
Readyset is basically reimplementing a full database, at the absolute bleeding edge of db research, enabling global partial replication of any kind of data.
A solution desperately needed, as databases grow.
You can think of it as an intelligent LRU cache in front of your database. An important step towards fast globally distributed applications.
I hope this project will get more publicity and adoption - it's very well deserved.
Re: Readyset: A MySQL and Postgres wire-compatible caching layer
#4I dont understand what the use case is for this.
If I have a front end, I would hope that the formated response is what were caching. Be that HTML or JSON.
If I cant read from that cache then I should be reading from fresh data all together? right?
Re: Readyset: A MySQL and Postgres wire-compatible caching layer
#5I dont understand what the use case is for this. If I have a front end, I would hope that the formated response is what were caching. Be that HTML or JSON. If I cant read from that cache then I should be reading from fresh data all together? right?
Sometimes, you have to deal with closed-source and legacy software for which there is no sufficient support in the application. This proxy can help boost the performance of such applications.
Re: Readyset: A MySQL and Postgres wire-compatible caching layer
#6I dont understand what the use case is for this. If I have a front end, I would hope that the formated response is what were caching. Be that HTML or JSON. If I cant read from that cache then I should be reading from fresh data all together? right?
What if it's a backend service that is not exposed to a frontend that receives html or Json. E.g a task that takes an id and a operation name and needs to fetch from the database a bunch of data to process.
Re: Readyset: A MySQL and Postgres wire-compatible caching layer
#7But the read side is already fairly trivial to scale with read replicas
Re: Readyset: A MySQL and Postgres wire-compatible caching layer
#8I dont understand what the use case is for this. If I have a front end, I would hope that the formated response is what were caching. Be that HTML or JSON. If I cant read from that cache then I should be reading from fresh data all together? right?
You are reading from "fresh" (though only eventually consistent) data. For many public facing queries that's enough.
After an initial query seen by their proxy, you can configure all future queries of the same kind to be pre-computed.
So I think it makes more sense to think of it like an auto-updating materialized view available with the click of a button rather than a cache.
There are some more under-the hood details here: https://docs.readyset.io/concepts/overview#how-does-readyset...
Re: Readyset: A MySQL and Postgres wire-compatible caching layer
#9I dont understand what the use case is for this. If I have a front end, I would hope that the formated response is what were caching. Be that HTML or JSON. If I cant read from that cache then I should be reading from fresh data all together? right?
How do you invalidate your cache? Is it complicated? What about search queries with many filters? What about responses that are unique per user? What about common queries that are shared between multiple views, do you constantly re-run those as your response cache is invalidated?
Re: Readyset: A MySQL and Postgres wire-compatible caching layer
#10But the read side is already fairly trivial to scale with read replicas
Yes to a degree, but not if you require/value consistency.