Using Redis as Only and Primary Database

Question

Here are the pros and cons of using redis.

Pros

1. Fast

2. transaction (because single threaded)

Cons

1. No secondary key support

2. No reindexing support

3. No reliable change streams unlike mongodb, dynamodb

4. Cost (since all the data has to be kept in memory, we need more and more ram)

5. No reliable persistence. (PS People say that rdb snapshot serves as a back up store for redis but help me understand what happens when we have 12 gb ram and we put 13 gb of data. redis will only have 12 gb of data, but if using the rdb snapshot if I bring up another redis with 20gb ram, will it have all my data or 1 gb is gone forever. How reliable is this mechanism??)

6. No auto balancing of keys. (application level sharding is a must)

Considering the above pros and cons I see only few use cases where we can have redis as Only and Primary data store. Like

1. Session store.

Am I missing anything? What additional capabilities does redis miss than other databases like mongodb, mysql (Here I am only talking about being production ready and reliability not starting nosql vs sql debate :) ).

Answer 1

Redis in fact is not a data store, nor is intended to do what a database (or maybe file system) was designed to do. As you correctly point out, if you need to store more information than can easily fit into RAM, then an in-memory cache solution such as Redis is no longer suitable. The other big risk with trying to use Redis as you would a database is that should Redis ever go down, you would lose all your state. Note that it is actually possible to configure Redis to take periodic snapshots into a persistent layer, such as a database. But even in this case, your cache would still be vulnerable in between snapshots. To remedy this, you could increase the frequency of database snapshots, but in this limit, your Redis cache would start to behave more like a database than a fast in memory cache.

So for what might Redis be suitable? Redis might be suitable for storing things like application session state. This tends to be reasonably small amounts of information, and also there isn't too much risk should Redis go down (perhaps in the worst case certain users would have to login again).