9 ms·

Readyset: A MySQL and Postgres wire-compatible caching layer

164 points by lsferreira42 3y ago

10000truths 3y ago
This sounds like it has heavy overlap with IVM. How does Readyset distinguish itself from existing solutions like pg_ivm or Materialize?
- jitl 3y ago
  ReadySet descends from Noira (https://www.usenix.org/conference/osdi18/presentation/gjengset https://www.usenix.org/conference/osdi18/presentation/gjengs...), which I view as the next generation of incremental dataflow technology after Naiad/Differential Dataflow/Materialize. The key difference is that Noira/ReadySet supports partial materialization and can reconstruct data on-demand, whereas Naiad/Differential Dataflow/Materialize must keep a complete materialization up to date. ReadySet can partially evict parts of the data flow and bring them back later if needed. In practical terms if you have a materialized view you want to maintain, in ReadySet you pay O(part of the materialized data flow you actually need), which is less than O(entire materialized view) you’d pay with Materialize.
  - benesch 3y ago
    (Materialize CTO here.) Partial materialization is indeed Noria's major contribution to dataflow technology, and it's impressive stuff. But I want to call out that there are a number of techniques that folks use with Materialize to avoid paying for O(entire materialized view). The two most common techniques are demand-driven queries using lateral joins [0] and temporal filters [1]. Noria's approach to partial materialization is automatic but gives the user less explicit control; Materialize's approach is manual, but gives the user more explicit control. The other major divergence between Materialize and Noria is around consistency. Noria is eventually consistent, while Materialize is strongly consistent. There is a caveat to Materialize's consistency guarantees today: we don't offer strong consistency across your upstream {Kafka, PostgreSQL, MySQL} and Materialize. You only get strong consistency within Materialize itself. But we've got an improvement for that in the works that'll be rolling out in the next few months. [0]: https://materialize.com/blog/lateral-joins-and-demand-driven-queries/ https://materialize.com/blog/lateral-joins-and-demand-driven... [1]: https://materialize.com/docs/transform-data/patterns/temporal-filters/ https://materialize.com/docs/transform-data/patterns/tempora...
    - jitl 3y ago
      Thanks for the great reply, I didn’t know about lateral join.
redwood 3y ago
Anyone 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
- lukoktonos 3y ago
  What do you mean by write support here? Readyset will apply writes via a replication stream from the upstream database.
  - jitl 3y ago
    I think they mean acting as a write-through cache. If you send writes to the cache and have the cache delegate those writes to the underlying DB you get consistent invalidation, and if the write-through cache is smart enough it can even be transactional with the underlying source of truth.
    - lukoktonos 3y ago
      Readyset does have some work and design done towards read-your-writes consistency, but it's still under development. The Noria paper does briefly touch on extending partial materialization with stronger consistency models via MVCC or other mechanisms as well.
- marceloaltmann 3y ago
  I found one case study on their blog - https://blog.readyset.io/medical-joyworks-improves-page-load-times-by-500-with-readyset/ https://blog.readyset.io/medical-joyworks-improves-page-load... > It will be interesting to see if any of these introduce some form of write support over time Writes performed by your application in Readyset are automatically proxied(redirected) to your database.
timsuchanek 3y ago
This 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.
zer00eyz 3y ago
I 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?
- tutfbhuf 3y ago
  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.
- jerrygenser 3y ago
  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.
  - marceloaltmann 3y ago
    You will add readyset between your backend and database in order to cache the data you fetch from db.
    - jerrygenser 3y ago
      I'm answering the comment above mine that is asking for a user case. I'm saying that my use case is an example where json/html caching is not sufficient. 100% agree with you.
- hobofan 3y ago
  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-work-under-the-hood https://docs.readyset.io/concepts/overview#how-does-readyset...
qaq 3y ago
But the read side is already fairly trivial to scale with read replicas
- eatonphil 3y ago
  Yes to a degree, but not if you require/value consistency.
  - qaq 3y ago
    Well Postgres has sync replication if you value consistency
- iknownothow 3y ago
  Not denying your point but in some applications (which aren't outliers) a good cache can increase number of requests served 100x. Achieving those with read-replicas is easy and possible but can be quite expensive. A read-replica doesn't give you perfect transactional guarantees as well. Read operations to the replica after a write operation to the leader might still give you stale data (lagging by a few milliseconds).
- jitl 3y ago
  Some queries might be too slow at p95 even on a read replica with no other clients. Those kinds of queries can benefit greatly from a materialized view, and incremental view maintenance as data changes.
larsnystrom 3y ago
They have a pretty good writeup on why you’d want to use this here: https://blog.readyset.io/dont-use-kv-stores/ https://blog.readyset.io/dont-use-kv-stores/
- darkwater 3y ago
  To be honest, I see more like a write-up about the shortcomings of using a classic cache system in front of your DB rather than about what Ready set does. Yes, it explains it but it could be better (for example, practical example of how you set a query to be cached, an overview how replication stream ingestion works under the hood etc)
giovannibonetti 3y ago
I imagine a good use case for this at its current stage would be for powering up a monitoring dashboard that runs ad-hoc queries against your operational DB. I've seen this situation in a previous Fintech company I worked at, where we had some people staring at dashboards all day long looking for issues in any of the subsystems.
exabrial 3y ago
One of the things we love about using JPA (We use EclipseLink) is it comes with caching, for free, and it’s transparent. You can mark any field as a cache index and it automatically tries the cache first. Updates are published and loaded into every nodes cache automatically, and you get fallback protection in the form of incremental version numbers on rows. The one thing it can’t handle however is range update queries or native queries that perform updates. You can just avoid them in your architecture… OR maybe this is the solution we’ve been looking we’ve been looking for! definitely going to give this a spin! Documentation looks very complete and I like there’s a UI to view the query cache.
fastest963 3y ago
What are some advantages to ReadySet versus read replicas from YugabyteDB or CockroachDB? A downside is that it appears to require a separate cloud subscription.
- marceloaltmann 3y ago
  You can deploy on your own via their .deb packages - https://readyset.io/download https://readyset.io/download The advantages is that reading from a cache will be faster than from a read replicas. The benefits increase even further if you have to perform computation on the fetched data.
potamic 3y ago
> ReadySet is licensed under the BSL 1.1 license, converting to the open-source Apache 2.0 license after 4 years. What does this mean?
- martypitt 3y ago
  Not the OP, but BSL is Source License that gives you access to use the source, with specific restrictions. Most commonly the restrictions prevent you from launching a competing offering. In their case, you can't offer database-as-a-service using their code. BSL typically also restricts production use - though it looks like ReadySet has relaxed that restriction. Finally, BSL reverts to a traditional open source license after a set period of time - in their case Apache 2 after 4 years. This means that code written today is licensed under BSL for 4 years, then automatically reverts to Apahce 2 thereafter.
- PeterZaitsev 3y ago
  The outdated security hole ridden useless code will eventually become Open Source. In practice I would count on either using software in compliance with BSL restrictions (which are generous) or seek commercial license
joeatwork 3y ago
This isn’t an open source project (which isn’t a bad thing! Just a non-obvious thing if you don’t scroll down their whole readme)
- gvsg-rs 3y ago
  [dead]
  - marceloaltmann 3y ago
    On top of that, quoting @martypitt reply: > Most commonly the restrictions prevent you from launching a competing offering. In their case, you can't offer database-as-a-service using their code. Meaning the self hosted version is free to use in any number of servers having in mind the competing offering restriction.
    - rbranson 3y ago
      Many people's biggest issue with BSL is that there are dozens of versions of the "additional use grant" which each have bespoke language with very critical clauses, none of which have any case law behind them (correct me if I'm wrong). Even though software may be licensed under "BSL" it isn't really a standard, even though proponents tend to use the term "BSL" as if it is the same as talking about "GPL" or "BSD". The MariaDB BSL used here is quite different than the HashiCorp BSL, for instance.
    - SahAssar 3y ago
      In this case the additional use grant is: Additional Use Grant: You may make use of the Licensed Work, provided that you may not use the Licensed Work for a Database Service. A ‘Database Service’ is a commercial offering that allows third parties (other than your employees and contractors) to access the functionality of the Licensed Work. IANAL but to me that sounds like it could be interpreted as almost any commercial work based on it since some part will "access the functionality", indirectly or directly. I know that is not what they intended, but the language is loose enough to allow almost any interpretation.
  - 3y ago
dpcx 3y ago
Pretty sure that this is the database that Jon Gjengset[0] was working on as part of his thesis project. There have been several videos shared by him during talks about the system. It's a really interesting concept. edit: Here's[1] a video where he talks about the concept [0]: https://www.youtube.com/@jonhoo https://www.youtube.com/@jonhoo [1]: https://www.youtube.com/watch?v=GctxvSPIfr8 https://www.youtube.com/watch?v=GctxvSPIfr8
BrentOzar 3y ago
In the Microsoft SQL Server space, several of these vendors have come and gone. My clients have been burned badly by 'em, so a few quick lessons learned: Be aware that there are hundreds of open issues[0] and dozens of pull requests [1], some of which involve clients being unable to connect or not supporting all components of the SQL language. Just because your database supports something, doesn't mean your caching layer will. It gets really ugly when a new version of your database comes out, with brand new features and language enhancements, and the caching layer doesn't support it. It may take months, or in some cases years, before the caching layer is feature-complete with the underlying database. If you want to use some of those language enhancements, then your app may have to maintain two connection strings - one for the caching layer, and one for direct database queries that the caching layer doesn't support. Your support teams need to learn how to diagnose problems with the caching layer. For example, this issue [2] talks about the level of work involved with understanding why newly inserted data isn't showing up in selects. I hope they succeed and deliver the concept, because it's one of the holy grails of databases. [0]: https://github.com/readysettech/readyset/issues https://github.com/readysettech/readyset/issues [1]: https://github.com/readysettech/readyset/pulls https://github.com/readysettech/readyset/pulls [2]: https://github.com/readysettech/readyset/issues/39 https://github.com/readysettech/readyset/issues/39
- gilbertbw 3y ago
  Regarding the new database version issue, I wonder why the caching layer can't just pass any query it is unable to process on to the underlying database? This would be more complex if the feature you are using does not return a normal table of results back (e.g. the pub/sub support in Postgres).
  - gvsg-rs 3y ago
    That is pretty much what Readyset does. The SQL parser identifies queries that are supported (and cached), and passes through all other requests to the backend database. As we expand query support, we allow users to cache more and more queries.
  - dspillett 3y ago
KingOfCoders 3y ago
This might be good tech and a good company. Once we used a distributed caching system in a startup which was open source. Then the open source version got cut features we needed, so we bought a license. Then the startup was bought up by a large software company and the license costs went 10x YoY with a one week notice. As our migration away from this tech was not done, because it was very complicated and tied into our application we had to pay. Luckily we also had been bought and the very large costs were not a problem. I would never again use something from a company that is crucial to our operations.
- marceloaltmann 3y ago
  That is a good point on the application changes. What is appealing from Readyset is that it does not require you to change your application code. You can just change your database connection string to point to it and it will start to proxy your queries to your database. From there you can choose what you want to cache, and everything else (writes, non supported queries, non cached read queries) will be automatically proxied to your database.
thom 3y ago
Someone knowledgeable might know: is this just incremental view updates? To what extent is the cache intelligent if parameters, where clauses, or aggregates change? I really love this space and have been impressed with Materialize, but even if you can make some intermediate state incremental, if your workload is largely dynamic you end up needing to jump the whole way to OLAP platforms. I’m hopeful that we’re closer and closer to having our cake and eating it here, and that the operational data warehouse is only round the corner.
- hobofan 3y ago
  They have a bit about their technical foundation here[0]. Given that Readyset was co-founded by Jon Gjengset (but has apparently since departed the company), who authored the paper on Noria[1], I would assume that Readyset is the continuation of that research. I wouldn't call that "just" incremental view maintenance, as it's a lot more involved than the simplest implementation of IVM (though obviously that is the end-goal). So it shares some roots with Materialize. They have a common conceptual ancestry in Naiad, where Materialize evolved out of timely-dataflow. [0]: https://docs.readyset.io/concepts/streaming-dataflow https://docs.readyset.io/concepts/streaming-dataflow [1]: https://jon.thesquareplanet.com/papers/osdi18-noria.pdf https://jon.thesquareplanet.com/papers/osdi18-noria.pdf [2]: https://dl.acm.org/doi/10.1145/2517349.2522738 https://dl.acm.org/doi/10.1145/2517349.2522738 [3]: https://github.com/TimelyDataflow/timely-dataflow https://github.com/TimelyDataflow/timely-dataflow
  - Jonhoo 3y ago
    Just poking my head in to say that I technically never departed ReadySet — what happened was that I co-founded the company, but was so burnt-out when it came to databases after my PhD that I decided to leave the running of the company to others. Then, US visa regulations made it so that I couldn't really be involved _at all_ if I wasn't an actual employee, which meant I truly was "just a founder" with no real involvement in the company's execution if you will. Now that I'm back in Europe, that's changing a bit, and I have regular calls with the CEO and such!
    - 3y ago
notapoolshark 3y ago
Slight tangent, but this reminds me of discussions I've seen in the Postgres email servers about native support for real-time materialized views. Does anyone know if we can expect to see something like this in a future version of Postgres?
- vira28 3y ago
  I don't know about the support in core but there is this extension https://github.com/sraoss/pg_ivm https://github.com/sraoss/pg_ivm
alwaysrusty 3y ago
From a tech perspective, this is really cool. From a use case perspective, could someone help me understand why a developer would adopt something like this over a database like Clickhouse, outside of some fintech use cases where milliseconds of latency really matter? I'd be worried about introducing an additional point of failure to the data stack. And, if this is like Materialize, I'd be worried about this not suppporting ad hoc queries -- only precomputed ones.
- hodgesrm 3y ago
  > rom a use case perspective, could someone help me understand why a developer would adopt something like this over a database like Clickhouse, outside of some fintech use cases where milliseconds of latency really matter? Concurrency. ClickHouse works best with a relatively small number of concurrent queries: hundreds to low thousands, not 10s of thousands or more. That allows each query to hog more resources and get done quickly.
- Culonavirus 3y ago
  > From a use case perspective, could someone help me understand why Imagine a legacy system that has a method that dynamically query-builds a massive query based on several method parameters (say 10 or 20), this method is used in two dozen places or more. The underlying tables are used in a million other places. Rewriting the query building method or, even worse, changing the underlying data model, would be expensive. Now imagine that you could speed up some of these queries WITHOUT changing your code or model or rolling your own cache solution (the invalidation of which is always a real PITA). All this basically for free. I don't think "why a developer would adopt something like this over a database like Clickhouse" is the right take. They do not compete. It's not about "adopting a database", that decision has been typically made a long time ago in a galaxy far far away and by someone else than you. Of course unless you work on green field projects or small enough projects that "adopting a different database" is even a question. I'd love some of that stuff :) ... one of the biggest systems I worked on for several years had close to 700 mysql tables (yea, not colums, tables), basically anything that was anywhere near the core of the system took ages to change and test. I can't possibly imagine the investment it would require to move that system from mysql to something else while not making a billion bugs along the way. I could imagine using something like Readyset, especially if it handles cache invalidation for you based on underlying model data changes.
AYBABTME 3y ago
Love the work. Looks quite similar to what PlanetScale Boost does[1]. Basically the same but as a front-end to someone's existing database? (disclaimer: I work at PS). [1]: https://planetscale.com/blog/how-planetscale-boost-serves-your-sql-queries-instantly https://planetscale.com/blog/how-planetscale-boost-serves-yo...
- Jonhoo 3y ago
  They're both based on the techniques outlined in the Noria paper (https://www.usenix.org/conference/osdi18/presentation/gjengset https://www.usenix.org/conference/osdi18/presentation/gjengs...) and my thesis (https://jon.thesquareplanet.com/papers/phd-thesis.pdf https://jon.thesquareplanet.com/papers/phd-thesis.pdf), so not terribly surprising they carry some resemblance :p
mdaniel 3y ago
I just wanted to give a high five for having Jepsen tests for this: https://github.com/readysettech/readyset/tree/stable-240117/jepsen#jepsen-tests-for-readyset https://github.com/readysettech/readyset/tree/stable-240117/...
ltbarcly3 3y ago
Trying to add transparent caching to a transactional database is just a bad idea and cannot work. Anyone who says it works for them is just in the period after putting it in place and before when they realize why it cannot work. If it was possible to just slap a cache in between you and the db and magically make shit fast, DB vendors would have done that 20 years ago. Billions of dollars a year is put into relational db development. Papers are published every week, from theoretical ways to model and interact with data to practical things like optimizing query execution plans. Unless Readyset can point to a patent or a paper that has fundamentally revolutionized how database will be built from today forward it is going to be crap and will burn you.

164 points by lsferreira42 3y ago

This sounds like it has heavy overlap with IVM. How does Readyset distinguish itself from existing solutions like pg_ivm or Materialize?

jitl 3y ago
ReadySet descends from Noira (https://www.usenix.org/conference/osdi18/presentation/gjengset https://www.usenix.org/conference/osdi18/presentation/gjengs...), which I view as the next generation of incremental dataflow technology after Naiad/Differential Dataflow/Materialize. The key difference is that Noira/ReadySet supports partial materialization and can reconstruct data on-demand, whereas Naiad/Differential Dataflow/Materialize must keep a complete materialization up to date. ReadySet can partially evict parts of the data flow and bring them back later if needed. In practical terms if you have a materialized view you want to maintain, in ReadySet you pay O(part of the materialized data flow you actually need), which is less than O(entire materialized view) you’d pay with Materialize.
- benesch 3y ago
  (Materialize CTO here.) Partial materialization is indeed Noria's major contribution to dataflow technology, and it's impressive stuff. But I want to call out that there are a number of techniques that folks use with Materialize to avoid paying for O(entire materialized view). The two most common techniques are demand-driven queries using lateral joins [0] and temporal filters [1]. Noria's approach to partial materialization is automatic but gives the user less explicit control; Materialize's approach is manual, but gives the user more explicit control. The other major divergence between Materialize and Noria is around consistency. Noria is eventually consistent, while Materialize is strongly consistent. There is a caveat to Materialize's consistency guarantees today: we don't offer strong consistency across your upstream {Kafka, PostgreSQL, MySQL} and Materialize. You only get strong consistency within Materialize itself. But we've got an improvement for that in the works that'll be rolling out in the next few months. [0]: https://materialize.com/blog/lateral-joins-and-demand-driven-queries/ https://materialize.com/blog/lateral-joins-and-demand-driven... [1]: https://materialize.com/docs/transform-data/patterns/temporal-filters/ https://materialize.com/docs/transform-data/patterns/tempora...
  - jitl 3y ago
    Thanks for the great reply, I didn’t know about lateral join.

redwood 3y ago

Anyone 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

lukoktonos 3y ago
What do you mean by write support here? Readyset will apply writes via a replication stream from the upstream database.
- jitl 3y ago
  I think they mean acting as a write-through cache. If you send writes to the cache and have the cache delegate those writes to the underlying DB you get consistent invalidation, and if the write-through cache is smart enough it can even be transactional with the underlying source of truth.
  - lukoktonos 3y ago
    Readyset does have some work and design done towards read-your-writes consistency, but it's still under development. The Noria paper does briefly touch on extending partial materialization with stronger consistency models via MVCC or other mechanisms as well.
marceloaltmann 3y ago
I found one case study on their blog - https://blog.readyset.io/medical-joyworks-improves-page-load-times-by-500-with-readyset/ https://blog.readyset.io/medical-joyworks-improves-page-load... > It will be interesting to see if any of these introduce some form of write support over time Writes performed by your application in Readyset are automatically proxied(redirected) to your database.

timsuchanek 3y ago

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

zer00eyz 3y ago

I 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?

tutfbhuf 3y ago
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.
jerrygenser 3y ago
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.
- marceloaltmann 3y ago
  You will add readyset between your backend and database in order to cache the data you fetch from db.
  - jerrygenser 3y ago
    I'm answering the comment above mine that is asking for a user case. I'm saying that my use case is an example where json/html caching is not sufficient. 100% agree with you.
hobofan 3y ago
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-work-under-the-hood https://docs.readyset.io/concepts/overview#how-does-readyset...

qaq 3y ago

But the read side is already fairly trivial to scale with read replicas

eatonphil 3y ago
Yes to a degree, but not if you require/value consistency.
- qaq 3y ago
  Well Postgres has sync replication if you value consistency
iknownothow 3y ago
Not denying your point but in some applications (which aren't outliers) a good cache can increase number of requests served 100x. Achieving those with read-replicas is easy and possible but can be quite expensive. A read-replica doesn't give you perfect transactional guarantees as well. Read operations to the replica after a write operation to the leader might still give you stale data (lagging by a few milliseconds).
jitl 3y ago
Some queries might be too slow at p95 even on a read replica with no other clients. Those kinds of queries can benefit greatly from a materialized view, and incremental view maintenance as data changes.

larsnystrom 3y ago

They have a pretty good writeup on why you’d want to use this here: https://blog.readyset.io/dont-use-kv-stores/ https://blog.readyset.io/dont-use-kv-stores/

darkwater 3y ago
To be honest, I see more like a write-up about the shortcomings of using a classic cache system in front of your DB rather than about what Ready set does. Yes, it explains it but it could be better (for example, practical example of how you set a query to be cached, an overview how replication stream ingestion works under the hood etc)

giovannibonetti 3y ago

I imagine a good use case for this at its current stage would be for powering up a monitoring dashboard that runs ad-hoc queries against your operational DB. I've seen this situation in a previous Fintech company I worked at, where we had some people staring at dashboards all day long looking for issues in any of the subsystems.

exabrial 3y ago

One of the things we love about using JPA (We use EclipseLink) is it comes with caching, for free, and it’s transparent. You can mark any field as a cache index and it automatically tries the cache first. Updates are published and loaded into every nodes cache automatically, and you get fallback protection in the form of incremental version numbers on rows. The one thing it can’t handle however is range update queries or native queries that perform updates. You can just avoid them in your architecture… OR maybe this is the solution we’ve been looking we’ve been looking for! definitely going to give this a spin! Documentation looks very complete and I like there’s a UI to view the query cache.

fastest963 3y ago

What are some advantages to ReadySet versus read replicas from YugabyteDB or CockroachDB? A downside is that it appears to require a separate cloud subscription.

marceloaltmann 3y ago
You can deploy on your own via their .deb packages - https://readyset.io/download https://readyset.io/download The advantages is that reading from a cache will be faster than from a read replicas. The benefits increase even further if you have to perform computation on the fetched data.

potamic 3y ago

> ReadySet is licensed under the BSL 1.1 license, converting to the open-source Apache 2.0 license after 4 years. What does this mean?

martypitt 3y ago
Not the OP, but BSL is Source License that gives you access to use the source, with specific restrictions. Most commonly the restrictions prevent you from launching a competing offering. In their case, you can't offer database-as-a-service using their code. BSL typically also restricts production use - though it looks like ReadySet has relaxed that restriction. Finally, BSL reverts to a traditional open source license after a set period of time - in their case Apache 2 after 4 years. This means that code written today is licensed under BSL for 4 years, then automatically reverts to Apahce 2 thereafter.
PeterZaitsev 3y ago
The outdated security hole ridden useless code will eventually become Open Source. In practice I would count on either using software in compliance with BSL restrictions (which are generous) or seek commercial license

joeatwork 3y ago

This isn’t an open source project (which isn’t a bad thing! Just a non-obvious thing if you don’t scroll down their whole readme)

gvsg-rs 3y ago
[dead]
- marceloaltmann 3y ago
  On top of that, quoting @martypitt reply: > Most commonly the restrictions prevent you from launching a competing offering. In their case, you can't offer database-as-a-service using their code. Meaning the self hosted version is free to use in any number of servers having in mind the competing offering restriction.
  - rbranson 3y ago
    Many people's biggest issue with BSL is that there are dozens of versions of the "additional use grant" which each have bespoke language with very critical clauses, none of which have any case law behind them (correct me if I'm wrong). Even though software may be licensed under "BSL" it isn't really a standard, even though proponents tend to use the term "BSL" as if it is the same as talking about "GPL" or "BSD". The MariaDB BSL used here is quite different than the HashiCorp BSL, for instance.
  - SahAssar 3y ago
    In this case the additional use grant is: Additional Use Grant: You may make use of the Licensed Work, provided that you may not use the Licensed Work for a Database Service. A ‘Database Service’ is a commercial offering that allows third parties (other than your employees and contractors) to access the functionality of the Licensed Work. IANAL but to me that sounds like it could be interpreted as almost any commercial work based on it since some part will "access the functionality", indirectly or directly. I know that is not what they intended, but the language is loose enough to allow almost any interpretation.
- 3y ago

dpcx 3y ago

Pretty sure that this is the database that Jon Gjengset[0] was working on as part of his thesis project. There have been several videos shared by him during talks about the system. It's a really interesting concept. edit: Here's[1] a video where he talks about the concept [0]: https://www.youtube.com/@jonhoo https://www.youtube.com/@jonhoo [1]: https://www.youtube.com/watch?v=GctxvSPIfr8 https://www.youtube.com/watch?v=GctxvSPIfr8

BrentOzar 3y ago

In the Microsoft SQL Server space, several of these vendors have come and gone. My clients have been burned badly by 'em, so a few quick lessons learned: Be aware that there are hundreds of open issues[0] and dozens of pull requests [1], some of which involve clients being unable to connect or not supporting all components of the SQL language. Just because your database supports something, doesn't mean your caching layer will. It gets really ugly when a new version of your database comes out, with brand new features and language enhancements, and the caching layer doesn't support it. It may take months, or in some cases years, before the caching layer is feature-complete with the underlying database. If you want to use some of those language enhancements, then your app may have to maintain two connection strings - one for the caching layer, and one for direct database queries that the caching layer doesn't support. Your support teams need to learn how to diagnose problems with the caching layer. For example, this issue [2] talks about the level of work involved with understanding why newly inserted data isn't showing up in selects. I hope they succeed and deliver the concept, because it's one of the holy grails of databases. [0]: https://github.com/readysettech/readyset/issues https://github.com/readysettech/readyset/issues [1]: https://github.com/readysettech/readyset/pulls https://github.com/readysettech/readyset/pulls [2]: https://github.com/readysettech/readyset/issues/39 https://github.com/readysettech/readyset/issues/39

gilbertbw 3y ago
Regarding the new database version issue, I wonder why the caching layer can't just pass any query it is unable to process on to the underlying database? This would be more complex if the feature you are using does not return a normal table of results back (e.g. the pub/sub support in Postgres).
- gvsg-rs 3y ago
  That is pretty much what Readyset does. The SQL parser identifies queries that are supported (and cached), and passes through all other requests to the backend database. As we expand query support, we allow users to cache more and more queries.
- dspillett 3y ago

KingOfCoders 3y ago

This might be good tech and a good company. Once we used a distributed caching system in a startup which was open source. Then the open source version got cut features we needed, so we bought a license. Then the startup was bought up by a large software company and the license costs went 10x YoY with a one week notice. As our migration away from this tech was not done, because it was very complicated and tied into our application we had to pay. Luckily we also had been bought and the very large costs were not a problem. I would never again use something from a company that is crucial to our operations.

marceloaltmann 3y ago
That is a good point on the application changes. What is appealing from Readyset is that it does not require you to change your application code. You can just change your database connection string to point to it and it will start to proxy your queries to your database. From there you can choose what you want to cache, and everything else (writes, non supported queries, non cached read queries) will be automatically proxied to your database.

thom 3y ago

Someone knowledgeable might know: is this just incremental view updates? To what extent is the cache intelligent if parameters, where clauses, or aggregates change? I really love this space and have been impressed with Materialize, but even if you can make some intermediate state incremental, if your workload is largely dynamic you end up needing to jump the whole way to OLAP platforms. I’m hopeful that we’re closer and closer to having our cake and eating it here, and that the operational data warehouse is only round the corner.

hobofan 3y ago
They have a bit about their technical foundation here[0]. Given that Readyset was co-founded by Jon Gjengset (but has apparently since departed the company), who authored the paper on Noria[1], I would assume that Readyset is the continuation of that research. I wouldn't call that "just" incremental view maintenance, as it's a lot more involved than the simplest implementation of IVM (though obviously that is the end-goal). So it shares some roots with Materialize. They have a common conceptual ancestry in Naiad, where Materialize evolved out of timely-dataflow. [0]: https://docs.readyset.io/concepts/streaming-dataflow https://docs.readyset.io/concepts/streaming-dataflow [1]: https://jon.thesquareplanet.com/papers/osdi18-noria.pdf https://jon.thesquareplanet.com/papers/osdi18-noria.pdf [2]: https://dl.acm.org/doi/10.1145/2517349.2522738 https://dl.acm.org/doi/10.1145/2517349.2522738 [3]: https://github.com/TimelyDataflow/timely-dataflow https://github.com/TimelyDataflow/timely-dataflow
- Jonhoo 3y ago
  Just poking my head in to say that I technically never departed ReadySet — what happened was that I co-founded the company, but was so burnt-out when it came to databases after my PhD that I decided to leave the running of the company to others. Then, US visa regulations made it so that I couldn't really be involved _at all_ if I wasn't an actual employee, which meant I truly was "just a founder" with no real involvement in the company's execution if you will. Now that I'm back in Europe, that's changing a bit, and I have regular calls with the CEO and such!
  - 3y ago

notapoolshark 3y ago

Slight tangent, but this reminds me of discussions I've seen in the Postgres email servers about native support for real-time materialized views. Does anyone know if we can expect to see something like this in a future version of Postgres?

vira28 3y ago
I don't know about the support in core but there is this extension https://github.com/sraoss/pg_ivm https://github.com/sraoss/pg_ivm

alwaysrusty 3y ago

From a tech perspective, this is really cool. From a use case perspective, could someone help me understand why a developer would adopt something like this over a database like Clickhouse, outside of some fintech use cases where milliseconds of latency really matter? I'd be worried about introducing an additional point of failure to the data stack. And, if this is like Materialize, I'd be worried about this not suppporting ad hoc queries -- only precomputed ones.

hodgesrm 3y ago
> rom a use case perspective, could someone help me understand why a developer would adopt something like this over a database like Clickhouse, outside of some fintech use cases where milliseconds of latency really matter? Concurrency. ClickHouse works best with a relatively small number of concurrent queries: hundreds to low thousands, not 10s of thousands or more. That allows each query to hog more resources and get done quickly.
Culonavirus 3y ago
> From a use case perspective, could someone help me understand why Imagine a legacy system that has a method that dynamically query-builds a massive query based on several method parameters (say 10 or 20), this method is used in two dozen places or more. The underlying tables are used in a million other places. Rewriting the query building method or, even worse, changing the underlying data model, would be expensive. Now imagine that you could speed up some of these queries WITHOUT changing your code or model or rolling your own cache solution (the invalidation of which is always a real PITA). All this basically for free. I don't think "why a developer would adopt something like this over a database like Clickhouse" is the right take. They do not compete. It's not about "adopting a database", that decision has been typically made a long time ago in a galaxy far far away and by someone else than you. Of course unless you work on green field projects or small enough projects that "adopting a different database" is even a question. I'd love some of that stuff :) ... one of the biggest systems I worked on for several years had close to 700 mysql tables (yea, not colums, tables), basically anything that was anywhere near the core of the system took ages to change and test. I can't possibly imagine the investment it would require to move that system from mysql to something else while not making a billion bugs along the way. I could imagine using something like Readyset, especially if it handles cache invalidation for you based on underlying model data changes.

AYBABTME 3y ago

Love the work. Looks quite similar to what PlanetScale Boost does[1]. Basically the same but as a front-end to someone's existing database? (disclaimer: I work at PS). [1]: https://planetscale.com/blog/how-planetscale-boost-serves-your-sql-queries-instantly https://planetscale.com/blog/how-planetscale-boost-serves-yo...

Jonhoo 3y ago
They're both based on the techniques outlined in the Noria paper (https://www.usenix.org/conference/osdi18/presentation/gjengset https://www.usenix.org/conference/osdi18/presentation/gjengs...) and my thesis (https://jon.thesquareplanet.com/papers/phd-thesis.pdf https://jon.thesquareplanet.com/papers/phd-thesis.pdf), so not terribly surprising they carry some resemblance :p

mdaniel 3y ago

I just wanted to give a high five for having Jepsen tests for this: https://github.com/readysettech/readyset/tree/stable-240117/jepsen#jepsen-tests-for-readyset https://github.com/readysettech/readyset/tree/stable-240117/...

ltbarcly3 3y ago

Trying to add transparent caching to a transactional database is just a bad idea and cannot work. Anyone who says it works for them is just in the period after putting it in place and before when they realize why it cannot work. If it was possible to just slap a cache in between you and the db and magically make shit fast, DB vendors would have done that 20 years ago. Billions of dollars a year is put into relational db development. Papers are published every week, from theoretical ways to model and interact with data to practical things like optimizing query execution plans. Unless Readyset can point to a patent or a paper that has fundamentally revolutionized how database will be built from today forward it is going to be crap and will burn you.