VortexKV is an in-memory, Redis-compatible key-value store written in pure Go without CGO. Its author, Anshu Garg, reports 6.87M operations per second in his September 18, 2026 project write-up. That figure is a pipelined throughput result from his own tests, under specific settings. It is not a universal speed, not an independent ranking, and not evidence that VortexKV beats Redis on every workload.
What the 6.87M figure actually measures
Throughput depends heavily on how a client sends requests. In a non-pipelined setup, a client sends one command and waits for its reply before sending the next. In a pipelined setup, the client sends a batch of commands before reading replies, which spreads network round trips and system-call costs across the whole batch. The article separates these cases, and each figure should be read with its own parameters: P is the pipeline depth (commands per batch) and C is client concurrency (parallel connections or clients).
As an Amazon Associate I earn from qualifying purchases.
| Case (as reported by the author) | Command | Pipeline depth (P) | Client concurrency (C) | Reported ops/sec |
|---|---|---|---|---|
| Direct concurrency, non-pipelined | Not stated | None (non-pipelined) | 50 | 210,970 |
| Medium pipeline | Not stated | 16 | 50 | 1,048,218 |
| Pipelined SET | SET | 64 | 50 | 2,688,172 |
| Pipelined GET | GET | 64 | 50 | 3,076,923 |
| Saturated pipelined PING | PING | 128 | 64 | 5,495,560 |
| Peak pipelined PING burst | PING | 64 | 100 | 9,411,764 |
The 6.87M headline does not appear as a single row in the rows reproduced here. Check the article’s full benchmark table to identify the exact configuration behind it. The 9.4M figure is the highest number in the table, but it is labelled a peak burst of PING commands at P=64 and C=100. It should not be read as typical throughput.
Why PING, GET and SET are not interchangeable
PING does almost no storage work. Its results therefore say more about the networking and dispatch path than about keyspace access. SET and GET touch stored data, so their numbers reflect locking, memory and value handling as well as networking. Comparing a PING burst with a SET result tells you about the design’s overhead, not about how it handles real writes.
How the design reaches those numbers
The article describes four implementation choices. Each is the author’s description of his design. The performance effect he attributes to each is his claim, and independent testing of those individual effects is not established.
Multi-reactor networking with SO_REUSEPORT
VortexKV uses a multi-reactor network design. On Linux it runs on epoll, and on macOS and BSD on kqueue. Its listeners use SO_REUSEPORT, which lets the kernel spread new connections across several worker listeners rather than funnelling them through a single accept loop.
Preallocated ring buffers and batched replies
Each active connection gets a preallocated cyclic ring buffer, which limits allocations on the read path. When pipelined requests arrive, the server gathers the replies and writes them together, combining up to 128 responses in one system call. The principle is simple: a separate write for every reply costs a kernel crossing each time, while one write for a batch spreads that cost. This is why the pipelined rows in the table are far above the direct-concurrency row. Batching only helps when clients actually pipeline.
Recommended Free Tools
A sharded keyspace with cacheline padding
The keyspace is split into 256 shards, each with its own lock, so operations on keys in different shards rarely wait on the same lock. Each shard’s lock state is padded to a 64-byte cacheline. Padding keeps one core’s lock updates from invalidating the cache line another core is using, a problem known as false sharing.
Integer command matching and in-place updates
Common commands are matched through a 32-bit integer representation rather than string comparison. When a key already holds a value, the server updates it in place instead of allocating a new one. Fewer allocations mean less work for Go’s garbage collector, which matters most under sustained load.
Comparisons with Redis 7.2 and DragonflyDB
The article compares VortexKV with Redis 7.2 and DragonflyDB using redis-benchmark. The results vary by operation and pipeline setting, and several rows show VortexKV behind a competitor. The honest reading is that VortexKV is competitive in some configurations, not that it wins across the board. Use the article’s own tables for the exact values, since they are the author’s measurements.
Rank #4
How to compare these numbers fairly
Before drawing a conclusion from any throughput comparison, confirm that both systems were measured under the same conditions:
- Command type: compare SET with SET, GET with GET, and PING only as a transport-overhead test.
- Pipeline depth and client concurrency: match P and C exactly. A P=64 result and a P=16 result are different tests.
- Key distribution and value size: results change when keys cluster in a few shards or values grow large.
- Latency percentile: the article frames its goal around p50 latency. Compare p50 with p50, not with p99.
- Hardware, operating system and software versions: record the CPU, core count, kernel, and the exact Redis and DragonflyDB builds.
- Benchmark tool and version: the article uses
redis-benchmark; confirm the same tool and version on each side.
What is and is not established
- Established as the author’s account: the throughput figures, the architecture described above, and the comparison tables as published in the article, dated September 18, 2026.
- Not established independently: the article calls its benchmark results “audited,” but it does not name an independent auditor. The hardware and software environment behind the numbers is not fully specified, so the results cannot be reproduced exactly from the article alone.
- Not established as a ranking: “fastest” is the author’s positioning. No independent comparison in this write-up confirms it.
Trying VortexKV yourself
VortexKV is open source under the MIT license. The project lives in the GargAnshu9468/vortexkv repository on GitHub, which includes the source code, build instructions, a Docker path, and scripts for reproducing the benchmarks. The article also shows Redis-client compatibility, so existing clients can be pointed at it for a first test.
Best Value
- Clone the repository and build from source, or use the Docker path described in the project’s instructions.
- Run the reproduction scripts on your own hardware before trusting any published number.
- Test with your own command mix, pipeline depth and concurrency, since those settings drive the result.
- Compare against your current server using the same client, the same keys and the same latency percentile.
Expect your results to differ from the author’s, especially on different CPUs, core counts and operating systems.
The Bottom Line
VortexKV’s 6.87M ops/sec is a real, author-reported pipelined throughput result, and the design choices behind it (multi-reactor networking, batched replies, sharded locks and in-place updates) are coherent for that kind of workload. Whether it is faster for your application depends on your pipeline depth, command mix and hardware, so measure it on your own setup before making a switch.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
