diff --git a/content/operate/oss_and_stack/management/optimization/benchmarks/index.md b/content/operate/oss_and_stack/management/optimization/benchmarks/index.md
index 99740d37c..d90caed0c 100644
--- a/content/operate/oss_and_stack/management/optimization/benchmarks/index.md
+++ b/content/operate/oss_and_stack/management/optimization/benchmarks/index.md
@@ -145,7 +145,7 @@ different options. If you plan to compare Redis to something else, then it is
 important to evaluate the functional and technical differences, and take them
 in account.
 
-+ Redis is a server: all commands involve network or IPC round trips. It is meaningless to compare it to embedded data stores such as SQLite, Berkeley DB, Tokyo/Kyoto Cabinet, etc ... because the cost of most operations is primarily in network/protocol management.
++ Redis is a server, hence, all commands involve network round trips. Embedded data stores do not involve network and protocol managements. To compare such products against Redis, apples to apples, command execution times should be used instead of end-to-end times.
 + Redis commands return an acknowledgment for all usual commands. Some other data stores do not. Comparing Redis to stores involving one-way queries is only mildly useful.
 + Naively iterating on synchronous Redis commands does not benchmark Redis itself, but rather measure your network (or IPC) latency and the client library intrinsic latency. To really test Redis, you need multiple connections (like redis-benchmark) and/or to use pipelining to aggregate several commands and/or multiple threads or processes.
 + Redis is an in-memory data store with some optional persistence options. If you plan to compare it to transactional servers (MySQL, PostgreSQL, etc ...), then you should consider activating AOF and decide on a suitable fsync policy.