I'm unfamiliar with Tarantool, but comparing a "server" database like redis with embedded ones like lmdb or rocksdb is so strange. It's comparing different engines to other whole cars.
NB: For anyone not in the know, "server" vs embedded here is about how your processes communicate with the DB, not about the type of hardware they're suitable to run on. An embedded database tends to be more of a library that attaches to a file or directory, often from a single process or occasionally from multiple processes on a single host.
"Server" databases tend to be connected to from processes on a number of servers over the network.
I keep using "server" in quotes here because I don't think I've seen that word used to make the distinction vs embedded databases reliable in literature.
Keeping the use case in mind (and it's possible evolution) will help pick the best tool for the job.
black sheep (python): 101,508 req/sec
actix (rust): 886,499 req/sec
yes, 101508/886499 = 0.11
but your "x is % of y" doesn't seem to capture the relationship very well here IMO.
you could also say, the rust library processes 773% more requests per sec.
or, the python library processes 89% fewer requests per sec.
(using: percent change = d2/d1-1)
personally I prefer multiples in terms of the larger thing. actix does over 8x the requests per/sec as the python lib.
https://www.techempower.com/benchmarks/#section=data-r18&hw=...
As you can see, the fastest Python implementation is just 11% of the top solution in Rust.
And your key/value store choice matters a lot. Redis is well known, but it's much slower than Tarantool or LMDB. Which is slower than RocksDB or Aerospike (though take this claim with a grain of salt, they can perform differently under different loads (writes, reads, updates, deletes) and different number of concurrent requests).