Redis changed their license, impact on Redis Oplog?

I just watched this video from Theo explaining that Redis moved away from the permissive BSD3 license. I was wondering how this may impact Redis Oplog? Or is this change only relevant for companies providing Redis as a Service to others?


As my understanding it only impacts companies like Amazon.
We’re already using Mongodb which has SSPL licenses. It’s the same as new Redis RSAL.
I think this will be new trend of opened source softwares.

1 Like

MongoDB, Elasticsearch, Terraform, and now Redis.

Elasticsearch has Opensearch and Redis has Valkey (supported by Linux Foundation i.e. the cloud providers).

We are staying with Redis for now due to cost considerations (we need persistence and a managed service - similar to MongoDB). We are revisiting Elasticache with this turn of events.


This should not impact Meteor at all. This change tries to restrict companies like Amazon who use Redis to make money without giving anything back to Redis. They had done the same with ElasticSearch. (And then Amazon pushed for OpenSearch.)


Just a few different thing in this story of Redis (as compared to Elasticsearch for example)

  1. One of the main developers who maintains Redis is paid/sponsored by AWS

  2. Redis the company is not the same entity who started/founded the opensource Redis

So technically speaking, Redis the company is just one of those service providers making a profit from a 3rd party opensource project.

More details here: Redis Switches to SSPLv1: Restrictive License Sparks Fork by Former Maintainers - InfoQ


As explained by others this should only impact service companies. Azure was on board at the time of the announcement. We have discussed this in Meteor Dispatches, here is the episode with approximate timestamp:


The big thing here is that this effects Meteor Software plans to add Redis as part of the Galaxy offering. Many good points in the opening video. The main reason for these changes like with MongoDB is the tragedy of commons. I highly disagree with the shade put on MongoDB Atlas as I found it to be the best cloud from all the ones I saw (if I want low DevOps and multi-region deployments).
That said I think it might be beneficial to look into alternatives like KeyDB or Dragonfly for the oplog tailing (at least given the speed thing) @grubba @nachocodoner .


The beautiful thing with the current redis oplog package for Meteor is that Redis is pretty much an industry standard. So when an outsider assesses its use, anyone can be reassured from the start that it is something they can easily rely on. Meteor would do well to try to avoid “exotic solutions” and just go for the mainstream. Even if that mainstream has some legal rumblings.

MDG could take the last published version before the license change. Amazon did that when they launched their DocumentDB right before the license change. If it’s just using basic API’s, could be worth it.

If Meteor Software plans to offer a “redis” service, the best choice now is the Redis fork Valkey:

  • still uses the original Redis license: BSD
  • Meteor Software doesn’t have to pay royalties
  • supported by the Linux Foundation + major cloud providers
  • it now has the broadest support of “redis” providers

Business-wise, for Meteor Software, it makes sense to support Valkey moving foward


You also have KeyDB and Dragonfly. It depends on what the setup is. KeyDB works the best on 2 threads and Dragonfly shines with 8.

The challenge that I am seeing with these solutions is the broad support from providers offering them as a service.

My expectation is that redis-oplog will become a core package, and hopefully some automated memory cache for Collections. Not being supported by AWS, GCP, and Azure will immediately lessen the appeal of any of these solutions.

Azure are completely onboard with Redis and I think the rest are going to follow suit or offer some of the alternatives which as far as I have said are all compatible with the Redis clients, so you can pick and choose which one best suites your setup and needs.

Valkey is supported by AWS, GCP, Alibaba and Azure.

The features will most probably diverge from the version forked. It doesn’t make sense for AWS, GCP, and Alibaba to create a fork if they will just continue to support Redis

Redis will be implementing a storage DB (they just acquired SpeeDB). Valkey already mentioned that this is not on their immediate pipeline as a feature