Redis is intentionally simple to use, and as a rule avoids complexity. Its protocol is text based and easy to parse, so it has hundreds of existing client libraries and can even be implemented in a microcontroller. The data structures Redis provides are used as basic building blocks for modeling data and accessing it, allowing developers to focus on their code and leave the actual management of these structures to the server. While each operation is guaranteed to be atomic and consistent with its data type, transactions are supported and ensure the atomicity of a block of consecutive operations. Lua scripts can be executed server-side (near the data) for composing custom workflows and reducing network traffic. Lastly, Pub/Sub allows Redis to act as an interprocess messaging system in which publishers and subscribers can communicate over channels.

Protocol, Transactions, Lua and Pub/Sub

Redis can be configured in several ways to address the limits and volatility of RAM. Other than replying with an “out of memory” error when memory is maxed out, Redis can be set up to evict data based on usage frequency, recentness or random policies. Furthermore, every key in Redis can be assigned with a time-to-live (TTL) that will cause the value to be deleted once expired.

Redis can be configured to persist to disk data that isn't ephemeral, and then use the persisted data when recovering from failures. Redis has two persistence options that may be used together, individually or not at all: snapshot backups and change logs. Redis database backups (RDB) are taken periodically and are meant for point-in-time recovery. Append-only files (AOF) flush a log of changes to disk on a configurable interval, and are for recovering the last known state of the database.

Data eviction, expiration and persistence

Redis uses replication to maintain one or more secondary replicas with updates from a single primary source. While replication itself is asynchronous, a client can ensure its success by blocking until a desired number of replicas has been updated. The replicas are usually read-only, and act as hot standby caches in the event of the primary failing.

Depending on whether Redis is used in single-instance or clustered mode, it can be set up for high availability. Redis Sentinel is a component that provides service discovery, failure detection and quorum-based failover from primary to secondary replica for single-instance databases. When running Redis in cluster mode, these capabilities are provided by the cluster itself.

Replication and high availability

Redis databases are scaled by partitioning the keyspace and assigning each partition dedicated memory, compute and network resources. Partitioning can be done by the application, an intermediate proxy or by Redis itself when used in cluster mode.

Redis cluster automatically partitions the data among multiple Redis servers across multiple nodes. Each member in the cluster, whether a primary or a secondary replica, manages a shared-nothing subset of the keyspace and all communicate via an internal bus. The cluster provides near-linear scalability while growing up to hundreds of nodes, and an interface that allows client applications to optimize access by discovering the cluster's topology.



Redis is an open source in-memory data structure store that is designed to be fast and simple. The name is an acronym for REmote DIctionary Server (pronounced "red-iss"), referencing the networked client-server and key-value data models that Redis uses.

Built for real-time performance most requests to Redis complete in less than a millisecond, allowing a single server to handle millions of concurrent requests every second. Redis is designed for simplicity; it’s easy to use and extends the developer's toolbox by managing a distributed store of data structures used by applications. Redis includes everything needed to run it—whether on a developer's workstation or in a highly available large-scale production environment—and is renowned for its rock-solid stability. It is used as a database, cache and a message broker wherever performance is key.

In-memory store

An in-memory store uses Random Access Memory (RAM) for storing data, and as such all Redis data is stored primarily in the server's main memory. RAM is the fastest storage media available and all data in it is immediately accessible to the server process, so both read and write operations demonstrate predictable low latencies.

Redis is architected to deliver the most out of RAM's low latencies across all platforms. The Redis server is written in portable, standard ANSI-C that is optimized for performance and low memory footprint. In order to facilitate data immediacy and maximize throughput, the server is implemented as an event loop run by a single process, avoiding the complexity of multi-threaded lock-based approaches.

Abstract data types

A Redis database is a dictionary that maps keys to their respective values and guarantees constant time access by key. A key's value can be of any supported data type, and Redis provides a Domain Specific Language (DSL) for manipulating it in a consistent and atomic manner. Redis provides a multitude of native abstract data types that can be combined to meet the diverse data needs and requirements of different access patterns efficiently.

Redis data types range from basic programming abstractions to specialized data structures. The basic data type is a binary-safe string that can also be used for numeric values and operations. Lists, Sets and Hashes are higher-level data structures for managing values by order, membership and name, respectively. Sorted Sets maintain a score-based order of their nested values, and support numeric, lexicographical and geospatial scoring and querying. Bitmaps and Bitfields are efficient for raw boolean and numeric data, whereas the HyperLogLog provides probabilistic estimates for set cardinality. On top of these, the open Redis modules API allows developers to extend Redis with their own custom data structures and logic for a wide variety of use cases.


Use Cases

Redis is often used as an external, secondary database alongside another primary data store that is either too slow or too expensive to meet performance needs. The data in Redis is derived from that of the primary store, and usually consists of index structures and summarization of the primary data. That data is then used by applications for the purpose of delivering real-time responsiveness, often when interacting with online users.

Typically Redis is employed as a secondary database for enabling services such as text search and autocomplete, geographical radius querying, IP ranges, managing custom indexes and serving pre-generated data.

Secondary database

Redis is used as a primary database and single source of truth for shared data by applications that demand predictable real-time performance at any scale. It is a popular choice for operational and analytical workloads that are at the core of many services. The variety of data types model needs that are common to all applications, while tunable data persistency and high availability options address a range of service-level requirements.

As a database, Redis can be used for storing almost any type of serializable data that represents a state in a distributed system. It is especially suitable for managing sessions, page and user statistics; counting, voting and real-time aggregates; leaderboards; job queues and locks; filtering, rate limiting and traffic shaping; and geospatial tracking.

Redis is used in ETL-like and batch processing systems, such as logging and monitoring systems, in which data flow is erratic or fast. By acting as a data buffer, Redis can handle bursts of traffic and store the incoming data. The data is either stored raw or partially processed by Redis, and is served in optimally sized chunks to successive processes in the workflow until it is stored in another data store.

Intermediate data store

Redis is an effective cross-application cache for almost every need, and as such has become ubiquitous. It provides a multitude of features that allow implementing effectual caching mechanisms with ease and flexibility. Key-level expiry allows precise control of the data invalidation at a time resolution of one second and is tuned for throughput prioritization. Random, least-frequently-used or least-recently-used eviction policies of all or volatile data are configurable at runtime and can be employed for handling memory pressure scenarios.

Redis powers many of the caching frameworks and libraries in most programming languages. Data cached in Redis varies among database data, views and queries; API requests; web pages, assets and code; and expensive computed results memoization.


Redis is used for delivering messages between processes in a distributed system. The List data type supports a set of blocking operations, which make it very suitable for implementing message queues. Pub/Sub capabilities allow message producers to publish arbitrary messages and keyspace event notifications in dedicated channels, that are immediately sent to all subscribing clients.

Message broker

Why Redis Enterprise?

  • Shared-nothing cluster architecture for linear scaling of performance
  • Seamless scaling by auto-sharding and rebalancing
  • High performance pipeline execution
  • Enhanced connection management and request scheduling 
  • Cluster support for every client using a single endpoint or with open source cluster API

Performance at scale

Built on the top of Redis by the team who develops the open source, Redis Enterprise provides the following benefits:

  • Cross-rack/zone/datacenter/geo replication
  • Instant auto-failover in single digit seconds
  • Enhanced data-persistence layer
  • Zero impact on throughput and latency while doing cluster operations like resharding, rebalancing, shard migration and software upgrade
  • Backup/restore, DR and built-in recovery tools

 HA, Durability, DR

  • Extension to Flash memory for >80% lower costs
  • Tiered memory access for max performance
  • Fewer servers due to maximized core usage
  • Multi-tenancy to maximize resource utilization

Redis on Flash + more saving

  • Reads/Writes in multiple geo regions to the same dataset
  • Local latencies, global availability
  • Built-in conflict resolution for simple and complex data types
  • Based on 10+ years of academic researches 

Active-Active Geo Distribution (CRDT-based)

  • Rapid-fire real-time search and indexing
  • Text, numeric and geospatial searches
  • Ideal for secondary indexing of data from any DBMS

Built-in Search (with RediSearch)

  • ReJSON - for native JSON data processing 
  • Redis Graph - built-in data structures and query processing for graph use cases
  • Redis ML - machine learning model serving for inline artificial intelligence
  • ReBloom - bloom filter functionality for Redis
  • Multi-shard coordination
  • Support for custom modules

Integrated Modules

  • Multiple authentication mechanisms
  • Role-based authorization for administration
  • Encrypted data-in-transit and data-at-rest
  • Tracking and logging of admin actions for forensics

Robust Security

  • UI/API/CLI-based provisioning, monitoring, alerting and reporting
  • Complete control of DevOps processes
  • Fully automated cluster management and orchestration
  • Built-in optimization/balancing of workloads
  • 24x7 expert support from the team that develops Redis

Automation and Support

Start Your Free Trial

Select Deployment Option:

Downloadable software for any cloud or private data center.



Fully managed Redis-e database-as-a-service in your virtual private cloud within major public clouds.


The fastest way to deploy a Redis database.
Fully managed, serverless and hosted database-as-a-service on major public clouds.


© 2018 Redis Labs | TERMS | PRIVACY