Redis and Sirius target slightly different use cases, although they share the goal of keeping data in memory. For our use case that motivated Sirius' development, we wanted to avoid doing I/O to an external system (even a fast one like Redis) in order to simplify development by having direct access to the data in native datastructures.
Additionally, we found that we needed some custom datastructures to get the performance we needed, so providing application developer control over those datastructures was an important motivation.
Our particular reference dataset (TV and movie data) had some application use cases that required custom data structures to get the in-memory performance we wanted. Sirius doesn't provide datastructures per se (and isn't really even a datastore itself)--it provides an eventually-consistent, replicated update stream that you can use to maintain your own datastructures. Having that developer freedom and control over the datastructures was an important design principle.
This isn't currently supported, although Sirius has some options that might be helpful. Sirius isn't really a data store per se; it's really a persistent, replicated update stream (transaction log) aimed at letting you build and maintain your own in-process representation of the dataset.
As such, you could set up a separate cluster running in "follower" mode, subscribing to the stream of updates and them writing them out to some other datastore.
Additionally, we found that we needed some custom datastructures to get the performance we needed, so providing application developer control over those datastructures was an important motivation.