If you release something new, you should make sure that your documentation contains useful information.<p>Even the most fundamental information like available configuration options, command-line arguments, deployment information and so on is missing.<p>Looking at the code it appears that you need Consul, Zookeeper and Redis to make this fly and the docs don't mention this anywhere. They (barely) explain how to run the SQL proxy on a local machine but thats it.<p>I wonder if the testimonials on your website are just pulled from thin air, I don't think any sane person would even experiment with this anywhere near production environments.
There are too many questions here. What does it not do? What's the overhead of monitoring the main DB and how's it done - triggers? Does it need schema changes? What about race conditions - can you guarantee none? What's the memory overhead you need for the cache? Can you control what gets cached?<p>> It can serve millions of reads per second on a single node ...<p>I'm not a network guy but that seems just astonishing - what is a 'node' here?<p>> ReadySet incrementally maintains result sets of SQL queries based on writes to the primary database.<p>So basically you've solved the general materialised view incremental update problem? That's an unsolved problem in general, surely?<p>Edit: not dissing but trying to see where the limits are.
I love the concept. Not needing to have extra code and logic for a caching layer seems very nice. In my experience, I haven't ever been in a situation where I needed super heavy caching, but this seems like it gives it to you "for free". Interested to see if we see more of ReadySet in the future.
Woah, 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).<p>There was a cool article about intercepting the Postgres connection with Elixir not long ago: <a href="https://docs.statetrace.com/blog/build-a-postgres-proxy/" rel="nofollow">https://docs.statetrace.com/blog/build-a-postgres-proxy/</a>
How does ReadySet interact with Row level security[1]? For RLS to work you'd need validation at the origin server anyway right?<p>[1]: <a href="https://www.postgresql.org/docs/current/ddl-rowsecurity.html" rel="nofollow">https://www.postgresql.org/docs/current/ddl-rowsecurity.html</a>
Interesting. I would love to see this available for MS SQL Server.<p>I've played with Safepeak (1) which runs on Windows Server. It was sold later to an Israeli company (2), which have since gone out of business and assets ended up with another company and now sold as ScaleArc (3)<p>The original SafePeak is available free but no maintenance or anything, so not really production ready. It works, as tested in a test environment but eight years without support or updates...<p>(1) <a href="http://www.safepeak.org/" rel="nofollow">http://www.safepeak.org/</a>
(2) <a href="https://en.wikipedia.org/wiki/SafePeak" rel="nofollow">https://en.wikipedia.org/wiki/SafePeak</a>
(3) <a href="https://www.devgraph.com/scalearc/" rel="nofollow">https://www.devgraph.com/scalearc/</a>
This looks really nice. I was reading about this and realized it had similar ideas to this [1] Phd thesis from Jon Gjengset. I checked his twitter [2] and it was based on his work indeed.<p>Great that someone is productionalizing this!<p>Btw, is Jon involved in ReadySet?<p>[1] Partial State in Dataflow-Based Materialized Views - <a href="https://github.com/mit-pdos/noria" rel="nofollow">https://github.com/mit-pdos/noria</a><p>[2] <a href="https://twitter.com/jonhoo/status/1537474261689872384" rel="nofollow">https://twitter.com/jonhoo/status/1537474261689872384</a>
PolyScale [1] is a serverless plug-and-play database edge cache. Our goal is for devs to be able to scale reads globally in a few minutes. It’s wire compatible with Postgres, MySQL, MS SQL Server (more coming including no-sql).<p>It has a global edge network, so no infrastructure to deploy and AI managed cache and auto invalidation, so no cache configuration needed.<p>[1] <a href="https://www.polyscale.ai/" rel="nofollow">https://www.polyscale.ai/</a>
> ReadySet is a lightweight SQL caching engine that precomputes frequently-accessed query results and automatically keeps these results up-to-date over time as the underlying data in your database changes<p>I don't see the point in using an extra app - you can do this natively in Postgres. Materialized views. <a href="https://www.postgresql.org/docs/current/rules-materializedviews.html" rel="nofollow">https://www.postgresql.org/docs/current/rules-materializedvi...</a>
> Traditional databases would compute the results of this query from scratch every time it was issued.<p>Is this really the case that queries can't be cached on traditional databases?
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?
Seems clever!<p>I'm curious what might be pathological cases, patterns of query watching and updates that give the cache a lot of work to do to keep up
I signed up for the waitlist! I noticed it asked about AWS, Azure, and GCP but we use Heroku. Hopefully, that won't put me too low on the list.<p>Do you have a sense for when people can try it? Most of our app is reads and we're using Rails + Redis and it's fine and sometimes a pain. Would love to try it.