Apache Kvrocks is a distributed key value NoSQL database from the Apache Software Foundation that uses RocksDB as its storage engine and speaks the Redis protocol, aimed at teams that need Redis-compatible access with lower memory cost and higher capacity than an in-memory deployment.

What it is

Kvrocks is a C++ database released under the Apache-2.0 licence and hosted by the Apache Software Foundation. It stores data on disk through RocksDB rather than holding the full dataset in memory, while exposing the Redis wire protocol so that existing Redis clients can connect without modification. On top of that protocol it adds namespace isolation, asynchronous binlog replication, high availability through Redis Sentinel, and a clustered mode that is centrally managed but reachable through any Redis cluster client. Its replication and storage design draws on the approaches used by rocksplicator and blackwidow.

The concrete problem it addresses is the memory cost and capacity ceiling of a purely in-memory key value store. A Redis deployment must fit its working set in RAM, which makes large datasets expensive to hold. Kvrocks intends to decrease that cost and increase capacity by moving persistence to RocksDB, so the same client libraries and much of the same command surface remain usable while the data lives on disk. In practice it replaces the Redis server process for workloads where the value is protocol compatibility rather than in-memory speed.

Key capabilities

• Redis compatible: any Redis client can access the database, and redis-cli -p 6666 connects to a running instance.
• Namespaces with per-namespace tokens, modelled on Redis SELECT but with token-based access per namespace.
• Asynchronous replication over a binlog, following the same pattern MySQL uses.
• High availability through Redis Sentinel, which performs failover when a master or slave fails.
• Cluster mode with centralized management, accessible from any Redis cluster client.
• RocksDB as the storage engine, plus built-in toggles such as -DENABLE_OPENSSL=ON for TLS support and -DENABLE_LUAJIT=OFF to build against Lua instead of LuaJIT.
• A single build driver, ./x.py, which also runs the C++ and Golang unit and integration test suites via ./x.py test cpp and ./x.py test go.

Who uses it and how

• Teams that need a Redis-compatible endpoint but whose dataset does not fit comfortably in RAM, which is the trade-off the project is designed around.
• Operators running replica sets with Sentinel failover, where a failed master or slave triggers promotion.
• Deployments that use cluster mode with centralized management while keeping existing Redis cluster client tooling.
• Multi-tenant setups that use namespaces with per-namespace tokens in place of a plain Redis SELECT index.
• Builds across Ubuntu, Debian, CentOS, RedHat, openSUSE, Arch Linux and macOS, with the README documenting prerequisites for each distribution.

The README does not list production deployments; it points to a Users page and to a GitHub issue titled "Who is using Kvrocks" where organisations are encouraged to add themselves.

Getting started

The fastest path is the published Docker image: docker run -it -p 6666:6666 apache/kvrocks --bind 0.0.0.0, with a apache/kvrocks:nightly tag also available on Docker Hub. To build from source, install the platform prerequisites, clone the repository, run ./x.py build, and start the server with ./build/kvrocks -c kvrocks.conf.

How it compares

The comparison the project states outright is with Redis: Kvrocks keeps Redis protocol compatibility and Redis client support, but trades in-memory storage for RocksDB on disk in order to lower memory cost and raise capacity. It also borrows its replication and storage model from rocksplicator and blackwidow, so it sits closer to disk-backed Redis-compatible stores than to an in-memory cache. It is offered under Apache-2.0 with no paid tier described in the README.

When to use it — and when not to

A self-hoster must build and operate the server, manage the RocksDB data on disk, configure binlog replication, and run Sentinel if failover is required; source builds additionally need a C++ toolchain, CMake, and OpenSSL development libraries on most platforms. It is a poor fit for anyone wanting a fully managed hosted service or the lowest possible latency from a pure in-memory dataset, since disk-backed storage is the central design choice. The repository shows steady activity, with the most recent push on 2026-09-18 and 250 open issues, but the README itself is sparse on operational detail and production references.

# Ubuntu / Debian
sudo apt update
sudo apt install -y git build-essential cmake libtool python3 libssl-dev

# CentOS / RedHat
sudo yum install -y centos-release-scl-rh
sudo yum install -y git devtoolset-11 autoconf automake libtool libstdc++-static python3 openssl-devel
# download and install cmake via https://cmake.org/download
wget https://github.com/Kitware/CMake/releases/download/v3.26.4/cmake-3.26.4-linux-x86_64.sh -O cmake.sh
sudo bash cmake.sh --skip-license --prefix=/usr
# enable gcc and make in devtoolset-11
source /opt/rh/devtoolset-11/enable

# openSUSE / SUSE Linux Enterprise
sudo zypper install -y gcc11 gcc11-c++ make wget git autoconf automake python3 curl cmake

# Arch Linux
sudo pacman -Sy --noconfirm autoconf automake python3 git wget which cmake make gcc

# macOS
brew install git cmake autoconf automake libtool openssl
# please link openssl by force if it still cannot be found after installing
brew link --force openssl

$ git clone https://github.com/apache/kvrocks.git
$ cd kvrocks
$ ./x.py build # `./x.py build -h` to check more options

$ ./x.py build -DENABLE_OPENSSL=ON

$ ./x.py build -DENABLE_LUAJIT=OFF

# The default build type is RelWithDebInfo and its optimization level is typically -O2.
# You can change it to -O0 in debug mode.

$ ./x.py build -DCMAKE_BUILD_TYPE=Debug

$ ./build/kvrocks -c kvrocks.conf

$ docker run -it -p 6666:6666 apache/kvrocks --bind 0.0.0.0
# or get the nightly image:
$ docker run -it -p 6666:6666 apache/kvrocks:nightly

$ redis-cli -p 6666

127.0.0.1:6666> get a
(nil)

$ ./x.py build --unittest
$ ./x.py test cpp # run C++ unit tests
$ ./x.py test go # run Golang (unit and integration) test cases

# add token
127.0.0.1:6666> namespace add ns1 my_token
OK

# update token
127.0.0.1:6666> namespace set ns1 new_token
OK

# list namespace
127.0.0.1:6666> namespace get *
1) "ns1"
2) "new_token"
3) "__namespace"
4) "foobared"

# delete namespace
127.0.0.1:6666> namespace del ns1
OK