ReadySet Core: next-generation SQL caching, freely available
1–10 of 59 posts
Re: ReadySet Core: next-generation SQL caching, freely available
#2Interesting. 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?
Re: ReadySet Core: next-generation SQL caching, freely available
#3Interesting. 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?
When you care about perf a lot more than consistency
Re: ReadySet Core: next-generation SQL caching, freely available
#4GitHub repo : https://github.com/readysettech/readyset
Re: ReadySet Core: next-generation SQL caching, freely available
#5Woah, I had the same idea not so long ago. Right now I'm using GraphCDN but would much rather cache at the database level. Looks like this could be a drop in for lots of people already on Postgres & MySQL (meaning no more dog-slow Rails apps).
There was a cool article about intercepting the Postgres connection with Elixir not long ago: https://docs.statetrace.com/blog/build-a-postgres-proxy/
Re: ReadySet Core: next-generation SQL caching, freely available
#6BSL :(
Re: ReadySet Core: next-generation SQL caching, freely available
#7Woah, I had the same idea not so long ago. Right now I'm using GraphCDN but would much rather cache at the database level. Looks like this could be a drop in for lots of people already on Postgres & MySQL (meaning no more dog-slow Rails apps). There was a cool article about intercepting the Postgres connection with Elixir not long ago: https://docs.statetrace.com/blog/build-a-postgres-proxy/
As an alternative, you can use WunderGraph (oss) to compile GraphQL Queries to REST Endpoints so that you can use fastly or Cloudflare as a CDN (and the Browser Cache obviously): https://wundergraph.com/docs/overview/features/caching
It supports configurable Cache-Control Headers per Operation and comes with ETags out of the box, so content can be invalidated easily.
Re: ReadySet Core: next-generation SQL caching, freely available
#8Woah, I had the same idea not so long ago. Right now I'm using GraphCDN but would much rather cache at the database level. Looks like this could be a drop in for lots of people already on Postgres & MySQL (meaning no more dog-slow Rails apps). There was a cool article about intercepting the Postgres connection with Elixir not long ago: https://docs.statetrace.com/blog/build-a-postgres-proxy/
As an alternative, you can use WunderGraph (oss) to compile GraphQL Queries to REST Endpoints so that you can use fastly or Cloudflare as a CDN (and the Browser Cache obviously): https://wundergraph.com/docs/overview/features/caching It supports configurable Cache-Control Headers per Operation and comes with ETags out of the box, so content can be invalidated easily.
That's pretty cool, thanks.
Re: ReadySet Core: next-generation SQL caching, freely available
#9Woah, I had the same idea not so long ago. Right now I'm using GraphCDN but would much rather cache at the database level. Looks like this could be a drop in for lots of people already on Postgres & MySQL (meaning no more dog-slow Rails apps). There was a cool article about intercepting the Postgres connection with Elixir not long ago: https://docs.statetrace.com/blog/build-a-postgres-proxy/
PM at ReadySet here - that's the idea! We think sub ms reads while still using SQL are pretty cool :)
If you want to dig-in more, hop into our community slack: https://readysetcommunity.slack.com/
Re: ReadySet Core: next-generation SQL caching, freely available
#10Interesting. 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?
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