Valkey 8.0.0 Is Out(github.com)
github.com
Valkey 8.0.0 Is Out
https://github.com/valkey-io/valkey/releases/tag/8.0.0
31 comments
to my knowledge and understanding it is the first valkey release that include features not just bug fixes!
This release is fully compatible with Redis OSS 7.2.4.
And that's why the OS movement matters so much.
Otherwise, Redis users would pretty soon be as miserable as Oracle users.
Otherwise, Redis users would pretty soon be as miserable as Oracle users.
Nah, Redis users would just keep using the last free version. Probably many of them will do that anyway because they missed the memo about Valkey. Like the poor people still using OpenOffice.
I have a few containers on the last OSS Elasticsearch version, and everybody uses the last filesystem-transparent Minio version. I am not sure why you are being downvoted, this is not a good plan but definitely happens in practice.
I only recently discovered minio and started using it for a project. What are you referring to by “last file system-transparent Minio version” for my own awareness?
Minio used to have a filesystem backend that would store each file as a file on the local filesystem. They removed this, so lots of people still use the last version before that.
https://blog.min.io/deprecation-of-the-minio-gateway/
https://blog.min.io/deprecation-of-the-minio-gateway/
> I am not sure why you are being downvoted, this is not a good plan but definitely happens in practice.
I guess this is more okay when the dated versions are not exposed publicly but are backing services, but in general it might be a question of time until some CVE puts you at risk or there's a bug that will never be fixed.
I like the idea of having "feature complete" software that you can use from now until the end of time (or at least the end of whatever product you're working on), I just don't think this is always feasible with the way we develop software.
I guess this is more okay when the dated versions are not exposed publicly but are backing services, but in general it might be a question of time until some CVE puts you at risk or there's a bug that will never be fixed.
I like the idea of having "feature complete" software that you can use from now until the end of time (or at least the end of whatever product you're working on), I just don't think this is always feasible with the way we develop software.
Hope to see this as an option in Elasticache soon. Feels like Valkey has the momentum over Redis now. Less sure about OpenSearch vs Elasticsearch...
What about client libraries? I feel a bit weird using valkey with redis client, but I also feel weird switching client libraries if they are not affected by any license change.
Has anyone used valkey in production? How does it compare to redis? Can it be used as a 1:1 replacement to redis or are there any caveats?
If you upgraded to 7.4, then redis switched to a proprietary dump format, and if you want to use those dumps you'll have to use a third-party tool to dump the data and put it back in valkey.
https://github.com/valkey-io/valkey/issues/845#issuecomment-...
https://github.com/valkey-io/valkey/issues/845#issuecomment-...
Redis switched to a proprietary dump format just to lock in users?
They only forked 5 months ago. Assuming you haven't adopted any brand new non-backward-compatible features in the last 5 months, then it should be a perfect drop-in replacement.
Haven't tried it in prod myself, but they claim full compatibility:
> This release is fully compatible with Redis OSS 7.2.4.
> This release is fully compatible with Redis OSS 7.2.4.
I'm from the project.
There shouldn't be any caveats of replacing Redis 7.2 and early to Valkey 8.0. I've talked with a few folks who have migrated and none so far have hit any issues, one even migrated from Redis 2.6.
There shouldn't be any caveats of replacing Redis 7.2 and early to Valkey 8.0. I've talked with a few folks who have migrated and none so far have hit any issues, one even migrated from Redis 2.6.
Congrats on the v8 release. It's super interesting to see that Heroku now uses Valkey instead of Redis [0], with no notes re: compatibility yet.
Yet another project to add to the books of successful forks re: rug-pull?
[0]: https://devcenter.heroku.com/articles/heroku-redis
Yet another project to add to the books of successful forks re: rug-pull?
[0]: https://devcenter.heroku.com/articles/heroku-redis
Heroku cant use OSS Redis anymore because of the license change to prevent Cloud vendors from running OSS Redis and charging for it
My point was that Redis' bet on cloud vendors paying them seems to be failing.
It is unfortunately not failing them ("unfortunately" because I very much dislike the path they took). They lost Heroku, which also didn't pay them before the license change, but they got others. I don't know if the information is public.
I'm torn on the moral issues of the re-licensing, but I'm firmly happy about the practical implications. Redis vs. Valkey is as competitive as it gets, since users can switch between the two so seamlessly (for now, at least). That's good for the industry. I expect to see a flurry of improvements to both in the coming years as they try to come out on top (some may be redundant, but I nonetheless think the pace will be faster).
Yeah, I guess I'm speaking from a sample size of 1 here since they don't share this information (and I'm too lazy to look around at what other cloud vendors are doing i.r.t. Valkey vs Reddit).
What "others" did they get, that you're aware of?
What "others" did they get, that you're aware of?
* Google added support to Valkey: https://cloud.google.com/memorystore
* AWS says they are moving: https://aws.amazon.com/blogs/opensource/why-aws-supports-val...
* Aiven added Valkey: https://aiven.io/blog/introducing-aiven-for-valkey
* Instaclustr mentioned moving: https://www.instaclustr.com/blog/redis-to-valkey/
* Oracle indicated support: https://blogs.oracle.com/cloud-infrastructure/post/oracle-su...
Azure is the main one sticking with Redis: https://azure.microsoft.com/de-de/blog/redis-license-update-...
I might edit this if I remember some more.
* AWS says they are moving: https://aws.amazon.com/blogs/opensource/why-aws-supports-val...
* Aiven added Valkey: https://aiven.io/blog/introducing-aiven-for-valkey
* Instaclustr mentioned moving: https://www.instaclustr.com/blog/redis-to-valkey/
* Oracle indicated support: https://blogs.oracle.com/cloud-infrastructure/post/oracle-su...
Azure is the main one sticking with Redis: https://azure.microsoft.com/de-de/blog/redis-license-update-...
I might edit this if I remember some more.
The azure post is very hand wavy, and it looks like azure isn’t even supporting redis 7, let alone redis minor version after the license change.
When will these money hungry vultures realize that you cannot transition a foss "brand" into a proprietary system no matter how you pitch the tree tier? You can't have your name recognition and eat it too. These groups don't realize that "NewThing from the developers of Redis" holds so much more weight than "Redis is now closed source and you have to pay for it"? There is a net negative value in detonating the bomb that is a license change versus making something new and throwing the existing name's support behind it. Just look at literally every well known license changed software becoming irrelevant while the foss fork with a new name has no problem getting traction? Just look at the graveyard of Solaris, OpenOffice and others. The open source community deeply despises these relicensing scams and has proven time and time again not to fall for ignorant consumer brand identity marketing tactics?
These companies are backed into a corner. Even if they "realize" that they are doomed the investors won't allow them to just shut down.
"NewThing from the developers of Redis" holds so much more weight than "Redis is now closed source and you have to pay for it"
I disagree with this part. The problem we're now seeing with open core is that almost everybody just wants the core. They don't want enterprise. They don't want the new thing.
"NewThing from the developers of Redis" holds so much more weight than "Redis is now closed source and you have to pay for it"
I disagree with this part. The problem we're now seeing with open core is that almost everybody just wants the core. They don't want enterprise. They don't want the new thing.
In this case, it's "Valkey, from the developers of Redis", and everybody wants the new thing. Because the people working on Valkey are in fact the people who worked on Redis before it went proprietary.
I don't think that was kelsey98765431's point. Of course people want the free thing. If Redis Labs released a new commercial thing, people do not want it regardless of the name.
I'm not suggesting it was kelsey98765431's point (though the thought crossed my mind that they might have been going for that). I was observing the irony that
> These groups don't realize that "NewThing from the developers of Redis" holds so much more weight than "Redis is now closed source and you have to pay for it"?
is in fact exactly what happened in this case, because NewThing is Valkey, it is from the developers of Redis, and that has indeed carried so much more weight.
> These groups don't realize that "NewThing from the developers of Redis" holds so much more weight than "Redis is now closed source and you have to pay for it"?
is in fact exactly what happened in this case, because NewThing is Valkey, it is from the developers of Redis, and that has indeed carried so much more weight.
My guy, the money-hungry vultures are more so the ones exploiting open-source without contributing anything back -- not even financially, let alone development or maintenance.
It's high time permissive OSS licenses died together with free maintenance and support.
It's high time permissive OSS licenses died together with free maintenance and support.
Both sides are leeching off somebody, one off a project that picked the wrong license, and the other off contributors who were mislead about a project's licensing intentions.
Oh, by no means am I belittling the rug-pull performed on the unpaid/non-commissioned? contributors.