Benchmarks

Test Setup

• Hardware: 6-core Intel i5-11400H (12 hardware threads)
• Network: Loopback TCP (127.0.0.1)
• Clients: 100 concurrent connections
• Operations: 1M total (10K per client)
• FyroDB: 1 node
• Redis: 6-node Redis Cluster (7 containers)
• Pipeline: 100 commands per batch
• Pub/Sub: 50 subscribers, 10 publishers, 200K messages, pipeline 200

All tests run with the same Go benchmark tool. Best of three runs.

KV Throughput

Mixed Workload Throughput

Pub/Sub Throughput

Resource Usage

Measured over the full benchmark suite across all processes.

Two things worth reading carefully:

• The DragonflyDB numbers are freshly measured for this release as a single multi-threaded node on the same 6-core/12-thread machine; the DiceDB column is an earlier measurement carried over and was not re-run, so treat it as indicative.
• DragonflyDB is a single multi-threaded process, so it is the closest single-node comparison to a single FyroDB node. It uses every core at once (peak CPU 957.5%) yet FyroDB still delivers higher throughput on every workload while using a fraction of the CPU. See Production Tips.

Why FyroDB Is Faster

Run Your Own Benchmark

The benchmark tool lives in the repository, so start from a clone:

git clone https://github.com/Rana718/FyroDB && cd FyroDB/bench
 
go run .                            # Full (KV + Pub/Sub + Mixed)
go run . -m key                     # KV only
go run . -m pub                     # Pub/Sub only
go run . -m mix                     # Mixed workloads only
go run . -p 6379                    # Against Redis
go run . -cluster addr1,addr2,...   # Against a cluster

The clone also ships shortcuts that start each side with a matched core count and tear it down again. Run task --list inside it to see them; the cluster ones are redis-up-12 / bench-redis-cluster-12 and fyro-up / bench-fyro-cluster-12, plus 6-core equivalents without the -12 suffix.

Reproducing these numbers depends on details that are easy to get wrong, so the committed Redis compose files pin one master per core, disable persistence, use host networking so no NAT hop sits on the critical path, and assign slot ranges that match the harness's own key-to-node mapping. Without that last part a handful of boundary slots get sent to the wrong node and the harness treats the resulting MOVED as fatal.