DiceDB: a Valkey fork with a spill module for larger working sets

The problem DiceDB targets: a working set bigger than the memory budget

A key/value cache is cheap until the dataset stops fitting in RAM. At that point you either pay for more memory or accept that a slice of your keys gets evicted, and the next read for an evicted key becomes a miss that travels back to the origin database. DiceDB attacks that second option. It is a fork of Valkey, which is itself a fork of Redis, and the README states it stays fully compatible with Valkey and Redis tooling and the SDK ecosystem. That compatibility matters more than any new command: an existing client library, an existing monitoring setup and an existing operational playbook keep working.

The audience is therefore narrow and specific. It is a team running Redis or Valkey as a cache in front of a slower store, where the hot set has grown past what the memory budget allows and the miss penalty is the thing hurting. It is not aimed at someone choosing a first database, and it is not aimed at someone who needs SQL, joins or secondary indexes.

How the spill module changes eviction

The README describes dicedb-spill as the differentiating capability: it transparently persists evicted keys to disk and restores them on cache misses, which the project frames as enabling larger working sets within fixed memory budgets. The Docker quick start says the spill module is enabled by default, uses RocksDB, and is configured with a maximum memory limit of 250MB. That is the mechanism in one sentence. Instead of a key being dropped when memory pressure forces eviction, it is written to a RocksDB-backed tier, and a later read that misses in memory can be served from that tier rather than from the origin.

The trade-off is latency. A spill hit is a disk read, not a memory read, so it sits between a cache hit and a round trip to your primary store. The README does not publish numbers for that difference, and no benchmark result is published in the repository files, so treat the ordering as the design intent rather than a measured figure. The other structural detail worth knowing is that DiceDB builds on Valkey, and the README warns that Valkey references still appear in logs, metrics and parts of the codebase. Anyone reading dashboards or grepping source should expect that.

Installing DiceDB with Docker and running your first commands

The README calls the official Docker image the quickest way to start and says it comes pre-configured. This command starts a container named dicedb-001, publishes the default Redis port, mounts a local data directory, and enables the spill module with its default 250MB limit.

docker run \
    --name dicedb-001 \
    -p 6379:6379 -v $(pwd)/data:/data/ \
    dicedb/dicedb

If you would rather set limits explicitly, the README shows the same image invoked with a server command and flags. This variant sets the DiceDB max memory limit to 500MB with --maxmemory 500mb, keeps the spill limit at 250MB, and turns off protected mode.

docker run \
    --name dicedb-001 \
    -p 6379:6379 -v $(pwd)/data:/data/ \
    dicedb/dicedb \
    dicedb-server \
      --port 6379 \
      --maxmemory 500mb \
      --protected-mode no

With the container running, the README's first-use sequence is to open the CLI inside the container and issue commands. You should see a PONG reply to ping, then OK for the set, the value back for the get, and an incrementing integer for incr.

docker exec -it dicedb-001 dicedb-cli
> ping
> set foo bar
> get foo
> incr counter

Building from source is also documented. The top-level Makefile delegates to src/Makefile, so make and make test are the two commands the README gives, and the supported platforms listed are Linux, macOS, OpenBSD, NetBSD and FreeBSD across little-endian and big-endian, 32-bit and 64-bit systems.

Running the server directly and pointing it at an existing config

The Docker path is not the only one. The README documents starting the server binary with defaults, with a configuration file, or with flags passed directly. The configuration-file form takes a path to a valkey.conf, which is a useful detail: existing Valkey configuration files are the expected input, not a new format. The flag form shows a replica pointing at another instance, plus a log level switch.

./src/dicedb-server
./src/dicedb-server /path/to/valkey.conf
./src/dicedb-server --port 9999 --replicaof 127.0.0.1 6379
./src/dicedb-server --loglevel debug

The README points at dicedb.io and the Valkey documentation for advanced configuration rather than reproducing it. That is a reasonable division of labour for a fork, but it also means the DiceDB-specific configuration surface, particularly the keys that control spill behaviour, is not enumerated in the README. You will be reading the project site for that.

Where DiceDB is the wrong choice

The most important limitation is historical, and the README states it plainly. DiceDB originally started as a Golang-based storage engine whose pitch was reactivity and higher throughput. That implementation is archived at dice-legacy, and the README says selected features from it will be gradually ported into the current codebase. If you arrived because of an older article or talk about DiceDB as a reactive database with a new query model, you are reading about a different codebase than the one shipping today. The current default branch is downstream/8.0, the layout is a Valkey fork's layout, and the current release is 1.0.0 from 2026-02-11.

Second, spill is not free. Every evicted key that gets written to RocksDB and later read back adds disk I/O to a path that used to be pure memory. On a workload where the hot set genuinely fits in RAM, the module is overhead you are carrying for nothing. Third, the README does not document rollback or a migration path off the spill tier, so if you enable it and the disk tier becomes a bottleneck, there is no documented way to unwind that. Fourth, this is a fork, so you inherit an upstream relationship: security fixes and features that land in Valkey have to be pulled downstream, and the repository keeps a valkey.conf, sentinel.conf and the standard runtest scripts, which tells you how closely the tree tracks its parent.

DiceDB vs Redis and Valkey: the actual difference

Redis is the original, and Valkey is the fork of Redis that DiceDB itself forks. Against both, the difference is not the command set, because DiceDB keeps the protocol and the tooling. The difference is the spill module. A stock Valkey or Redis deployment under memory pressure evicts according to its policy and the key is gone; the application takes the miss. DiceDB inserts a RocksDB-backed tier in that gap and tries to serve the miss from disk instead.

If your working set fits in memory, or if a miss is cheap because your origin store is fast, the extra tier buys you little and adds a component to operate. If misses are expensive and the dataset is much larger than the memory you want to provision, the tier is the whole point. That is the decision, and it is a memory-versus-disk-latency trade, not a feature checklist.

Worth noting for anyone comparing: the related searches around this project include queries about DuckDB and RocksDB. DuckDB is an analytical, columnar engine and solves a different problem entirely; RocksDB is the embedded store DiceDB uses underneath the spill module, not an alternative to it.

Maintenance, licence and upgrade cost

The repository is not archived. The last push was on 2026-04-23, which is roughly five months before the date this article is written, so the project is not being pushed to daily, and calling it actively developed would overstate what the timestamps show. The only release listed is 1.0.0 from 2026-02-11, so the release cadence is not yet something you can extrapolate from. The README carries a support section that asks readers to star the repository and sponsor the maintainer on GitHub, which tells you the project is funded at least partly by individual sponsorship rather than by a vendor with a commercial edition.

On licensing, the GitHub API reports the licence as NOASSERTION, meaning it could not be matched to a known identifier. The repository does contain a COPYING file at the top level, which is the file to read. Do not take a description of the licence from anywhere else, including this article; read COPYING in the tree you are actually deploying, and note that as a fork of Valkey the licence story may carry upstream obligations in addition to whatever DiceDB adds. That is a question for your legal review, not for a review of the code.

The upgrade cost is the ordinary cost of running a fork: you track the downstream/8.0 branch, you re-read the release notes for 1.0.0 and whatever follows, and you keep an eye on what upstream Valkey changes because you inherit its security posture. The repository includes a 00-RELEASENOTES file, which is where the changelog lives.

Editorial conclusion

Adopt DiceDB if you already run Valkey or Redis clients and your working set has outgrown the memory you are willing to pay for, because the spill module is the one capability the fork adds and the protocol stays compatible. Do not adopt it if you need the archived Golang engine's reactivity and throughput claims, since that implementation now lives in dice-legacy and the README only says selected features will be ported gradually. Before you commit, verify three things: that your client or SDK connects to port 6379 unchanged, that your eviction policy settings interact with spill the way you expect, and that the repository's COPYING file, which the GitHub API reports as NOASSERTION, is acceptable to your legal review.

Frequently asked questions

Official sources

1. dicedb/dicedb on GitHub
2. Issues
3. Project website
4. README
5. Releases