Databases: Part 5 — Redis and Valkey

Redis (Remote Dictionary Server) — an in-memory key–value data store that keeps all data in RAM. Because of this, operations complete in fractions of a millisecond. Redis is rarely the primary database of an application: it usually runs alongside PostgreSQL or MySQL and takes on tasks where speed matters — cache, sessions, queues, counters.

A Redis value can be not only a string but also a data structure: list, set, hash, sorted set, stream, bit array, HyperLogLog for approximate distinct counts, geo index. Each structure has its own atomic commands, so many tasks are solved with a single command without locks in the application.

License: what changed since 2024

Until spring 2024 Redis was distributed under the permissive BSD license. This causes some confusion in older articles and documentation.

• March 2024, Redis 7.4. The Redis company moved the project to two choice licenses — RSALv2 and SSPLv1. Both restrict offering Redis as a cloud service and are not recognized as open by the Open Source Initiative (OSI).
• March 2024, Valkey. In response, the community under the Linux Foundation created the Valkey fork based on the last BSD-licensed version (7.2.4). Valkey remains under the BSD license and is developed independently; as of September 2026 the active branch is 9.x.
• May 2025, Redis 8. A third license was added — AGPLv3, approved by OSI. Redis 8 can again be used as open software, but AGPL requires disclosing the source of a modified version if it is offered to users over a network.

For most companies that use Redis inside their product as a cache or session store, none of these licenses creates obstacles. You should study the license carefully if you provide Redis to customers as a service or distribute a modified version. If you need a permissive license without conditions, choose Valkey: it is protocol- and command-compatible with Redis 7.2, and existing client libraries work with it without changes.

What’s included in Redis 8

Previously advanced features were provided separately — as modules and the Redis Stack build. In Redis 8 they are included in the core release:

• Redis Query Engine — secondary indexes, full-text search and vector search (the former RediSearch module);
• JSON — store and modify JSON documents by individual fields;
• Time Series — time-series data;
• probabilistic structures — Bloom filters, Count-Min Sketch, Top-K and others;
• vector sets — a new data type for vector search.

In Valkey some of these features are developed as separate modules; before migrating check which ones your application needs.

Common scenarios

• Caching. The application stores in Redis the results of expensive queries to the primary database or ready-made page fragments and retrieves them from memory on subsequent requests. For a cache you set a memory limit and an eviction policy:

maxmemory 512mb
maxmemory-policy allkeys-lru

• User sessions. The session ID is the key, session data is the value with an expiration (SET session:abc ... EX 3600). Multiple application servers see the same sessions.

• Task queues. Lists (LPUSH/BRPOP) and streams (XADD/XREADGROUP) are used as a simple message broker. For example, Sidekiq in Ruby and RQ in Python are built on them; Celery can use Redis as a broker. The PUBLISH/SUBSCRIBE mechanism is suitable for real-time notifications, but messages are not persisted: if a subscriber was disconnected it will miss them.

• Counters and leaderboards. INCR atomically increments a view counter or login attempts, and sorted sets (ZADD, ZRANGE) allow maintaining leaderboards without recalculation.

• Rate limiting. A counter with a TTL is a standard way to limit the number of API requests from one address or user.

Persisting data to disk

Although Redis works in memory, data can be saved to disk and restored after a restart. There are two mechanisms.

• RDB — snapshots. At configured intervals Redis writes a full copy of the dataset to dump.rdb. The file is compact, convenient for backups and loads quickly. The downside: in a crash you lose changes since the last snapshot — typically a few minutes.

save 3600 1 300 100 60 10000   # snapshot if 1 key changed in an hour, 100 in 5 minutes, 10,000 in a minute

• AOF — operation log. Each modifying command is appended to a log, which is replayed at startup. With the default appendfsync everysec setting at most one second of writes is lost on crash.

appendonly yes
appendfsync everysec

Redis documentation recommends enabling both mechanisms if you need durability comparable to PostgreSQL. If Redis is used only as a cache, persistence can be disabled entirely (save "", appendonly no) — the data will be repopulated by the application.

For a backup it is sufficient to copy the RDB file: Redis creates it under a temporary name and renames it atomically, so copying the file while Redis is running is safe.

Security: basic configuration

Redis is designed to run inside a trusted network and should not be accessible from the Internet. One FLUSHALL command deletes all data, and via CONFIG an attacker can write a file to an arbitrary server directory. Instances exposed to the Internet are constantly found and hacked by automated scanners.

Minimal secure redis.conf for a server where Redis is used only by a local application:

bind 127.0.0.1 -::1
protected-mode yes
port 6379

# disable the default user and create a separate one for the app
user default off
user app on >very-long-random-password ~* &* +@all -@dangerous

What’s happening here:

• bind — Redis accepts connections only from the local address. If the application is on another server, specify the internal private-network address, not the public one;
• protected-mode yes — since 3.2 Redis, when there is no password and it is bound to all interfaces, will only respond to local clients;
• user ... -@dangerous — access control lists (ACLs, introduced in Redis 6) forbid the application user from dangerous commands: FLUSHALL, CONFIG, KEYS, DEBUG and others. This category also includes INFO, CLIENT and SORT; if your application or its library uses them, explicitly allow the needed commands, for example +info. For a very simple setup you can use a single password with requirepass, but ACLs are more flexible.

Also, close port 6379 in the firewall and run Redis under a separate unprivileged user rather than root.

Common mistakes

• Port exposed to the outside via Docker. The -p 6379:6379 in docker run or ports: - "6379:6379" in Compose publishes the port on all server interfaces, and Docker adds its own iptables rules that bypass ufw. In the official Redis image protected mode is disabled by default. If Redis is needed only by neighboring containers, do not publish the port; for access from the host use 127.0.0.1:6379:6379.
• No memory limit. Without maxmemory the cache grows until RAM is exhausted and the OOM killer terminates the process.
• KEYS * on a production dataset. It iterates all keys and blocks the server during the scan. Use SCAN to iterate keys safely.
• Using Redis as the sole store of critical data without AOF. On restart you may lose everything that was not included in the last snapshot.

Advantages

• Speed. Latency is fractions of a millisecond, hundreds of thousands of operations per second on a single instance.
• Data structures. Many tasks are solved by built-in commands without extra code.
• Atomicity. Commands are executed sequentially, so counters and queues work correctly without locks in the application. For sequences of commands there are MULTI/EXEC transactions and Lua scripts.
• Replication and clustering. Replicas for high availability, Redis Sentinel for automatic failover, Redis Cluster for sharding data across nodes.
• Ecosystem. Client libraries exist for all popular languages.

Disadvantages

• Size limited by RAM. All data must fit in memory, and RAM is more expensive than disk.
• No complex queries. Joins and arbitrary aggregation like in SQL are not available. The Query Engine in Redis 8 adds indexed search but does not replace a relational database.
• Durability requires configuration. By default you may lose data from the last few minutes.
• Commands run in a single thread. Since 6.0 network I/O can be spread over several threads (io-threads), but commands themselves still execute sequentially, so one slow command delays all others.

When to use

Redis or Valkey are useful when the primary database struggles with frequent identical queries, when a shared session store is needed for multiple servers, or when you need a simple and fast task queue. Store the only copy of irreplaceable data in them only with AOF enabled, replication, and regular backups. For a small project with one server and moderate load, an in-process memory cache or queries to a well-indexed database are often sufficient and a separate Redis is not necessary.