Redis is a NoSQL in-memory key-value repository. It allows you to create atomic operations over built-in data types. It isn’t a cache tool, but a complex repository which can be used simultaneously as a queue, stack or message broker. Regarding the fact, that Redis is available as the Azure service, it can be used as a distributed cache with low latency, high permeability and availability.

Differences from other database systems

Redis has popularized the idea that the system can be considered both as a both storage and cache, using design where the data is constantly edited and read from the computer’s main memory, but also stored on a disk in a format that is not suitable for random access to data, but only for reconstructing data from the memory after the system restart.

At the same time, Redis provides a data model that is very atypical, compared to other RDBM systems, where user commands don’t describe a query to the database, but they describe specific operations that are triggered on specified abstract data types. Data must therefore be stored in a manner that is suitable for quick subsequent call up without the assistance of the database system in a form of secondary indexes, aggregates or other normal RDBM functions.

Redis implementation frequently uses Fork to duplicate data retention processes, so the parent process continues to serve clients, while the subsidiary process creates a copy of data to disk.


Redis usually keeps the entire data set in its memory. Some versions can be configured to what Redis refers to as a virtual memory. In that case, the data set is stored on disk. The persistence is thus achieved in two ways. One way is a so-called snaphotting and has a semi-persistent durability mode, where the data set is asynchronously transmitted from memory to disk in RDB format. Since version 1.1, a safer AOF variant is implemented. This method works as an operation modifying the data set in memory. Redis can rewrite AOF files in the background to avoid the continuous growth of the captured capacity.

In default, Redit writes data into the filesystem at least every two seconds, with more or less robust options that can be set as needed. In a case of complete system failure, with default settings applied, only data from last few seconds are lost.

The advantages of using Redis

  • The possibility of storing large key-value pairs. Redis allows storage of key-value pairs up to 512 MB. It is therefore possible to add up to 1 GB of data within a single input.
  • Own hashing mechanism. Redis has its own hashing mechanism called Redis Hashing. It saves data in the form of a key and a map, i.e. string fields and string values.
  • Data replication. Redis can be used to create effective replications in any time. Cache service will thus be available even if one of the slave nodes wouldn’t be available. Nodes are resilient and can overcome failures.
  • It has clients in many popular programming languages. Redis has client API available in many popular programming languages, such as C, Ruby, Java, JavaScript or Python.
  • Saving large amounts of data to cache. Sometimes, it is necessary to load millions of lines of data to cache within a short time. Mass insertion supported by Redis can solve this situation.
  • Support for Raspberry Pi or ARM. Redis can be also installed on Rapsberry Pi, allowing IoT applications.
  • Simple protocol. Redis protocol allows a simple client implementation. Redis client communicates with the server using the Redis Serilization Protocol (RESP). This protocol is simple to implement and is perfectly human-readable.
  • Transactions support. Redis supports transactions, so it is possible to queue orders instead of executing them one by one.

The disadvantages of using Redis

  • It is an in-memory repository. All data must therefore be able to fit in the repository.
  • Absence of a query language. There is no language but only commands. Redis also doesn’t support relational algebra.
  • Security. Neither of the two persistence solutions is as safe as a real transaction server. It also has only basic security at the level of instances.