Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstalliTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
VortexKV is an in-memory, Redis-compatible key-value store written in pure Go with no CGO. Its author, Anshu Garg, reports throughput above 6.8 million operations per second in a project write-up published September 18, 2026. That figure comes from pipelined requests. It is not a single speed the store reaches under every workload, and every number in the write-up is the author’s own report rather than an independent measurement.
What the 6.87M figure measures
The headline number belongs to a pipelined test setup. In a pipeline, a client sends many commands before waiting for replies, which removes much of the round-trip waiting that limits non-pipelined traffic. Throughput therefore depends heavily on pipeline depth, the number of concurrent client connections, and the command being measured. Change any of those and the result changes.
The write-up does not tie 6.87M to one specific row of its tables, so treat it as a headline rather than a configuration you can reproduce directly from the published figures. The closest reported values are the pipelined PING and GET/SET results below.
Free tools Windows power users keep installed
One-click scans. No signup required.
The reported throughput cases
The article separates direct, non-pipelined concurrency from several pipelined cases. The table lists each case with the parameters the author gives. Where the text does not state the command mix for a row, the cell says so.
#1 Best Overall
| Case (as labelled by the author) | Command mix | Pipeline depth (P) | Client concurrency (C) | Reported ops/sec |
|---|---|---|---|---|
| Direct concurrency | 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 |
PING measures the server’s handling of a trivial command, so it shows the ceiling of the networking path more than the cost of reading or writing data. SET and GET do real keyspace work and are the more useful guide for an application that stores and fetches values. The write-up gives latency as a p50 target of under 120 microseconds, but it does not attach that latency to a specific row of the table.
How the design is meant to produce those numbers
The article describes several implementation choices. Each is the author’s account of the design. The text does not independently prove that each one causes the speed it is credited with.
Networking: multiple reactors
VortexKV uses a multi-reactor design. Each worker runs an event loop, using epoll on Linux or kqueue on macOS and BSD. Workers listen with SO_REUSEPORT, which lets the kernel spread new connections across them, so a single accept loop does not become the bottleneck.
Buffers and batched writes
Each active connection has a preallocated cyclic ring buffer, which keeps allocations off the read path. When many pipelined responses are ready, the server collects them and writes them together, in some cases up to 128 responses per system call. The principle is simple: a system call has a fixed overhead, so sending many replies in one call spreads that cost across all of them. The gain is largest when clients pipeline heavily, which is consistent with where the highest figures appear.
Keyspace: sharded locks and in-place updates
The keyspace is split into 256 independently locked shards. Each shard’s lock state is padded to a 64-byte cacheline, which reduces false sharing when different cores touch neighbouring locks. Common commands are matched using a 32-bit integer representation, and existing values are updated in place where possible, which reduces allocation and garbage collection pressure.
How the comparisons with Redis and DragonflyDB read
The article compares VortexKV with Redis 7.2 and DragonflyDB. The author says the comparisons used redis-benchmark. Results differ by operation and pipeline setting, and some rows show VortexKV behind a competitor. Read these tables as a set of individual results, not as a verdict that VortexKV leads on every workload.
Rank #4
A fair comparison needs the same command, pipeline depth, client concurrency, key distribution, latency percentile, hardware, operating system and benchmark version on both sides. The article gives some of these parameters, but it does not fully document the test machine or environment, so the cross-product rankings cannot be settled from the published text alone.
What is and is not independently established
- The article describes its benchmark results as audited. It does not name an independent auditor, and no independent audit of these figures is identified in the material reviewed.
- The source code and benchmark reproduction scripts are published in the project’s GitHub repository, GargAnshu9468/vortexkv, which makes the tests repeatable in principle.
- Reproduced results on other hardware may differ from the author’s figures, and the article’s own numbers come from one author’s setup.
- “Fastest” is the author’s positioning. It is not an established ranking across Redis, DragonflyDB and other stores.
How to check the numbers on your own machine
- Clone the GargAnshu9468/vortexkv repository from GitHub and read the README for build instructions. The article also describes a Docker path.
- Start VortexKV on the same host where you plan to test, and record the operating system, CPU model, core count and kernel version.
- Run the reproduction scripts in the repository, keeping command type, pipeline depth and client concurrency identical to the case you are checking.
- Run the same workload against Redis 7.2 on the same host, using the same benchmark tool, so that only the server changes.
- Repeat each run several times and compare medians, not a single peak, because pipelined throughput varies with system load.
What to take from the article
The write-up is a useful account of how a Go server can use multi-reactor networking, batched writes, preallocated buffers and sharded locks to push pipelined throughput into the millions of operations per second. It is less useful as proof of a universal speed ranking. The reported figures are specific to their command types, pipeline depths and client counts, and the strongest of them, the PING bursts, measure the networking path more than real data work.
Best Value
VortexKV is open-source software under the MIT license. Hardware, cloud or other purchases are not required to try it, though a machine with enough cores to run the load generator and the server separately will give cleaner results.
The article is a first-person project account by its author. Treat its numbers as his reported measurements of his own build.
Source: Anshu Garg, “How We Built the Fastest In-Memory Key-Value Store in Pure Go (Hitting 6.87M ops/sec Without CGO),” published September 18, 2026.
Recommended Free Tools
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.
