A relatively common question posted to the general Redis e-mail mailing list, asks whether Redis is a good choice for a variety of uses, such as running reviews on a website, caching results from MySQL databases queries, or meeting other specific requirements that the poster might have for his/her project, product, website, or system. In general, Redis excels as a tool for a fast read/write of data and has been used with great success by small and large organizations alike for a wide range of uses. Salivator Sanfilippo makes a strong case that Redis does not need to replace the existing databases but is an excellent addition to an enterprise for new functionalities or to solve sometimes intractable problems1.

Being a single-threaded application with a small memory footprint, Redis achieves durability and scalability through running multiple instances on the current multicore processors available in data centers and cloud providers. With Redis-rich master-slave replication and now with Redis clusters are released in production, creating multiple Redis instances are relatively cheap operation in terms of memory and CPU requirements, allowing you to both scale and increase the durability of your larger applications.

Redis allows you to conceptualize and approach challenging data analysis and data manipulation problems in a very different manner as compared to a typical relational data model. In an SQL-based relational database, the developer or database administration creates a database schema that organizes the solution domain through normalizing the data into columns, rows, and tables with connecting joins through foreign-key relationships.

Even other NoSQL data storage technologies such as MongoDB or Elasticsearch require the data to be modeled as JSON document data structures first before being loaded into the actual storage. Redis skips this intermediate but necessary step in these other technologies, by just providing sets of commands for specific data structures such as strings, lists, hashes, sets, and sorted sets. In this approach, you are algorithmically interacting with your data, constructing solutions directly with how the data is stored in Redis and the available commands, and enabling a more direct tuning and monitoring of the underlying operating system's memory and hard disk space.

Thinking how data is represented and managed as basic computing data structures such as lists, hashes, and sets, allows you to grasp both positive and negative characteristics of the data and its structures in a more fundamental, mathematical fashion. Going through the intermediate structuring process such as normalizing your data for a relational database or converting it into a JSON document for MongoDB or Elasticsearch, while valuable, imposes a structure that Redis does not. As you architect your solutions, you may discover that your data and your problem need more of the persistence and structure of a technology other than Redis, but in the meantime, your exploration of the properties and the structure of data in Redis will be a useful exercise because of this algorithmic approach to your information and problem.

Redis may not be the best technology to use when you have a large amount of infrequently used data that does not require immediate access. An SQL-based relational database or a document-store NoSQL technology such as CouchDB or MongoDB may be a better choice than Redis. However, with Redis Cluster now fully supported as of version 3, large datasets can be sharded and used in Redis as a distributed key-value data store. As more organizations and individuals gain experience with the use of Redis Cluster, expect that this reason to not choose Redis for a project will fade away.