Tendis: Redis on RocksDB, and what the persistent storage model actually costs you

What Tendis actually is: the Redis protocol over a log-structured engine

The README is unambiguous about the two halves of the design. Tendis is a high-performance distributed storage system that is fully compatible with the Redis protocol, and it uses RocksDB as the storage engine, with all data stored to disks through RocksDB. The user connects with an ordinary Redis client, and the README says the application hardly needs to change.

So the name Redis in the description is a compatibility statement, not an implementation one. Nothing here reimplements Redis in memory and then adds durability as an afterthought. Every read and every write is served by a log-structured merge tree, which is why the project can hold far more data than fits in memory and why the README frames the storage cost saving as the headline benefit.

Written in C++ and built with CMake, judging by the README and the root `CMakeLists.txt`. The tree confirms the shape: `src/` for the implementation, `bin/` for the binary, `pack/` for packaging, `tests/` for the suite, `utils/` for helpers, and `performance_test_tools/` for benchmark tooling. There are shell scripts at the root that name the workflow outright, `testall.sh`, `unittest.sh` and `redistest.sh`, which is what you would expect from a project that takes Redis protocol conformance seriously enough to script it separately.

One detail worth flagging up front: GitHub shows the licence field as NOASSERTION, while the README states Tendis is licensed under the GNU General Public License Version 3.0 and points at a `LICENSE.txt` in the root. Trust the file over the sidebar field. GPLv3 matters a great deal if you intend to ship Tendis inside a proprietary product.

Building from source on Linux x64

The requirements are short and specific: g++ at version 5.5 or newer, which the README ties to the c++17 standard the code uses, and cmake at version 3.13.0 or newer.

The clone needs the `--recursive` flag because RocksDB arrives as a submodule, and the README repeats the submodule update as a separate step:

$ git clone https://github.com/Tencent/tendis.git --recursive
$ git submodule update --init --recursive
$ mkdir build
$ cd build & cmake ..
$ make -j12

Two things stand out. The out-of-source build is explicit, `mkdir build` then `cd build`, which is what you want when CMake generates a lot of state. And `make -j12` is not a generic suggestion: the README's hardware section specifies a 2.50GHz 48-core machine, so that parallelism figure is calibrated to a server, not a laptop.

There is also a `CMakeLists.txt` at the root plus `code-format.sh` and `CPPLINT.cfg`, which means the project has settled on a lint pass as part of its workflow. `mkreleasehdr.sh` alongside `pack/` suggests release headers are generated rather than hand-edited. If you are evaluating whether this is production-shaped code, the presence of a formatting script and a lint config is a reasonable first signal.

The distribution is Linux x64 only, per the README badge. There is no Windows or macOS build mentioned anywhere, and the configuration file in the tree is `tendisplus.conf`.

Running the server and the configuration file

Starting the server takes one command and one configuration file, both named in the tree:

$ ./build/bin/tendisplus tendisplus.conf

The binary is `tendisplus`, not `tendis`, and the configuration file sits at the repository root as `tendisplus.conf`. The README does not inline the file contents, so the defaults are not visible from the documentation. What is visible is the port.

$ redis-cli -p 51002

Port 51002 is not the Redis default of 6379, which makes sense for a system that may sit beside an in-memory Redis. That detail also shows up in every benchmark command in the README, so treat 51002 as the project's own convention rather than something to change casually.

The README's run-and-play section stops there. It does not document a Docker image, a systemd unit, an install target, or the full set of supported commands, and it says as much by pointing readers to the Chinese documentation at tendis.cn for anything deeper. For a project whose entire compatibility claim rests on command support, that is the gap you will feel first: you cannot tell from this README whether a particular command is implemented, and you will find out at runtime.

The testing story is at least spelled out. `sh ./testall.sh` is the check the README recommends after making changes, and it clearly wraps the more granular `unittest.sh` and `redistest.sh` scripts in the tree.

Reading the benchmark section critically

The README publishes memtier_benchmark invocations and a latency table, which makes this one of the more transparent open source storage projects to read. It is also where the caveats live, and they are worth reading before the numbers.

./memtier_benchmark -t 20 -c 50 -s 127.0.0.1 -p 51002 --distinct-client-seed --command="set __key__ __data__" --key-prefix="kv_" --key-minimum=1 --key-maximum=500000000 --random-data --data-size=128 --test-time=1800

Twenty threads, fifty connections, thirty minutes per run, run against a machine with 192GB of memory and NVMe SSDs, with `tendisplus` configured to 56 workers. The command set covers set, get, incr, lpush, sadd, zadd and hset, so the intent is breadth across types rather than a single hot path.

The latency table is the most honest number in the repository: SET at 1.6ms for 99%, 2.2ms at 99.9%, 6.9ms at 99.99% and 9.4ms at the full 100% mark. Compare that with the sub-millisecond figure most people picture when they hear Redis, and the storage engine's cost becomes visible.

The payload section then admits the limit of its own test: the README says the data is not big enough, so most of it stays in memory, which is why GET QPS barely moves across payload sizes. That is a fair disclosure about the experiment's design, and it also means the headline QPS chart should not be read as a measurement of the disk-backed path.

The topic list on the repository includes `rocksdb vs redis`, which is the right question to be asking. The answer here is that Tendis trades latency and some command surface for capacity and cost, and the benchmark section is best used to size that trade rather than to declare a winner.

Cluster behaviour: gossip, online migration, and failover

The distributed design is decentralised, and the README compares it to Redis Cluster. Nodes talk to each other with a gossip protocol, all nodes in a cluster can be routed to the correct node when a user accesses, and nodes discover each other automatically, detect faulty nodes, and keep the application almost unaffected when a master fails.

Three claims in that paragraph deserve separate treatment. Automatic discovery plus fault detection is what makes failover invisible to the client, and it is the feature that would otherwise require Sentinel. Auto-promotion of a replica to master on failure is stated as behaviour rather than as a design goal, which is a stronger claim.

Online data migration between nodes is the one that matters most for adoption, because it is what lets you grow the cluster without a maintenance window. The README pairs it with linear scalability up to 1,000 nodes. Take the number as a stated target rather than a measured result, since the benchmark section covers single-node QPS and says nothing about cluster-wide throughput at that size.

The README describes Tendis Hybrid Storage Edition as Redis and Tendis working together, which is a genuinely interesting angle: the two occupy different tiers of the same dataset, and the README claims an 80% operating cost reduction in scenarios where cold data dominates storage. That figure comes from the project itself and no test methodology is given for it in this repository, so treat it as a vendor claim about its own commercial configuration.

For failover semantics specifically, the repository is quiet. No configuration keys for replica count or promotion timeouts appear in the README, and the only documentation offered is the support page and discussion groups at tendis.cn.

Release cadence, versioning, and maintenance state

The release tags tell an unusual story that is worth understanding before you plan an upgrade. The most recent is 2.8.4-rocksdb-v8.5.3, published on 2026-07-08. Before that came 2.8.3-rocksdb-v8.5.3 on 2025-12-23 and 2.8.0-rocksdb-v8.5.3 on 2025-03-18. Every one of those tags encodes the RocksDB version it was built against.

That naming has a practical consequence: the Tendis version and the RocksDB version move together, so upgrading Tendis means accepting a new storage engine too. For a system where all data lives in RocksDB, a storage engine change is a much bigger deal than a library bump, and you should read the release notes for the engine before you schedule the upgrade.

The gaps between the three releases are also worth noting. Roughly nine months between the March 2025 and December 2025 tags, then seven more to July 2026. Each release body is a single line pointing at the Chinese documentation for details, so the changelog is external to this repository.

On maintenance, the last push was on 2026-09-17 and the repository is not archived, so work is ongoing. Note that the default branch is `unstable`, while the clone instructions in the README reference the repository name without a branch. If you want the stable path, the tagged releases are the safer reference than a branch name.

The README also carries a copyright note worth flagging for anyone doing a compliance review: the Tencent code was previously in the name of THL A29 Limited, which has been de-registered, and previously distributed copies should be treated as naming Tencent.

Editorial conclusion

Tendis makes sense when your key count no longer fits in memory and you would rather not shard a Redis deployment by hand. Because everything lives in RocksDB, storage capacity is bounded by disk rather than RAM, and the same Redis client connects to it. The costs are real and mostly visible in the documentation itself: writes go through a log-structured engine, so the published SET latency percentiles run from 1.6ms at the 99th to 9.4ms at the tail, and the benchmark caveat that most of the test data fits in memory tells you the payload numbers do not scale the way a headline QPS suggests. Build it with cmake and make against a Linux x64 box, start it with `./build/bin/tendisplus tendisplus.conf`, connect on port 51002, and read the Chinese documentation at tendis.cn for the parts the README summarises in a few lines.

Frequently asked questions

Official sources

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