DEV Community: Softalink LLC

We Rewrote VictoriaMetrics in Rust. It Now Beats the Original on Every Benchmark Metric

Softalink LLC — Tue, 07 Jul 2026 17:02:38 +0000

VictoriaMetrics is one of the fastest open-source time-series databases in existence. Its Go implementation is not naive code that a rewrite trivially beats — it is a decade of careful engineering around the garbage collector: object pools everywhere, unsafe byte↔string casts, buffer recycling as a way of life.

That made it the perfect subject for a question we wanted a rigorous answer to: how much performance is left on the table when the same algorithms run without a GC?

Today we're releasing the answer as EsMetrics, an Apache-2.0 licensed, from-scratch Rust implementation of VictoriaMetrics single-node (reference v1.146.0). On the TSBS benchmark suite it outperforms the original Go server on every metric — ingestion throughput and query latency across all ten devops query types — on both Linux and Windows, while answering queries byte-for-byte identically.

The numbers

TSBS cpu-only, scale 100 (8.64 million metrics), four workers, medians of three paired back-to-back rounds against the official v1.146.0 release binaries on identical hardware:

Ingestion

platform	Go v1.146.0	EsMetrics	delta
Linux (4 cores)	3.59M metrics/s	5.14M metrics/s	+43%
Windows 11 (8 cores)	2.99M metrics/s	4.95M metrics/s	+66%

Queries — all ten TSBS query types are faster. Mean latency improvements range from −11% to −59% on Linux and −52% to −82% on Windows. The heaviest query in the suite (double-groupby-all, aggregating a thousand series) went from 102ms to 41ms on Windows.

Correctness — 750 replayed TSBS queries produce byte-identical JSON to the Go server, down to Go's shortest-round-trip float formatting. Roughly 600 tests translated from the upstream Go suites run in CI on Linux and native Windows.

All raw per-round data, the harnesses, and the honest caveats live in the repo. The short version of the caveats: two machines, one workload family, and a handful of sub-millisecond stats that flip within the TSBS client clock's ~0.5ms Windows quantization.

Byte-identical or it didn't happen

The single most valuable decision in the project was a correctness rule: every response must match the Go server byte-for-byte.

That sounds obsessive. It is. It's also the only reason we can publish benchmark numbers with a straight face — a "faster" database that returns subtly different aggregates is just a broken database with good marketing.

The rule had teeth. It forced us to port Go's exact float formatting (Go's strconv produces shortest-round-trip decimal in fixed notation — 1e21 prints as 1000000000000000000000), the exact staleness-interval semantics of the rollup engine, the exact tie-breaking in the deduplication algorithm, and the exact JSON escaping of the response templates. A replay harness diffed our responses against the Go binary on identical data after every optimization. It caught more real bugs than the ported unit tests did.

Where the performance actually came from

The straight algorithmic port — faithful data structures, idiomatic Rust — won the ingestion benchmark immediately and lost most of the query benchmarks. Everything after that was profile-driven. A few of the changes that mattered:

1. The parallel unpacking pipeline. Go's netstorage collects per-series block references without decoding, then unpacks blocks across per-CPU workers. Our first port did all of that on the HTTP connection thread; the profile showed 26% of query time in series materialization and 30% in zstd/varint decode, all serialized. Porting the two-pass design — reference collection, then decode+merge across a persistent work-stealing pool with per-worker scratch buffers — cut the heaviest query's latency by 60%.

2. Caching what the upstream re-decodes. VictoriaMetrics decompresses data blocks on every query. We added a size-bounded, sharded decoded-block cache keyed by (part, offset), invalidated on part drop. This is a deliberate deviation from the faithful port — and it's worth 25-60% on read-heavy queries. Deterministic destruction made the invalidation story clean: when the last reference to a merged-away part drops, its cache entries go with it.

3. Allocation discipline where it counts. The ingest path is allocation-free at steady state: a zero-copy Influx parser that borrows from the request buffer (lifetimes prove what Go's unsafe casts merely hope), thread-local conversion arenas, and an ingestion API that never clones metric names. Sharded caches keyed by xxh64 with precomputed hashes — one hash per lookup — replaced the standard library's SipHash maps on the hot path.

4. Small mechanical wins that compound. SWAR varint decoding (eight bytes at a time instead of restart-per-byte). K-way merging of overlapping blocks instead of concatenate-and-stable-sort. A fair round-robin evaluation pool so a heavy query can't starve the sub-millisecond ones behind it.

The Windows cliff

The most instructive chapter was Windows. Under Wine, everything looked great. On real Windows hardware, multi-series queries were suddenly seven times slower than Go — 748ms for a query Go served in 102ms — while ingestion still won comfortably.

The profile pattern was strange: the degradation scaled linearly with series count, roughly half a millisecond per series. That's not an algorithm problem; that's a per-allocation problem. The Windows default process heap serializes concurrent allocations under a global lock. Go never notices — it ships its own allocator. Rust, by default, uses the system allocator.

One line — #[global_allocator] static GLOBAL: MiMalloc — took that query from 748ms to 81ms.

Windows had two more lessons that required structural fixes rather than tweaks. WinSock's shutdown() doesn't interrupt a thread blocked in recv the way POSIX does, so graceful shutdown needed ticked reads on idle connections. And deleting a merged-away data part's directory costs tens of milliseconds on Windows (hello, Defender) — which occasionally landed on whichever query thread happened to drop the last reference. The fix mirrors what the upstream does: a dedicated background remover thread, with drains at close boundaries so tests and restarts stay correct.

What the borrow checker found

Porting is a brutal code review. Two findings stand out.

The concurrency one: under concurrent ingestion, series registration had a window where two workers could assign different TSIDs to the same new series — in one benchmark load we counted 2,214 "shadow" series, which silently inflated every query that touched the affected hour. Striped single-flight locks closed it. The race pattern exists upstream in a milder form; the Rust port made it visible because our profiling kept asking why Windows queries unpacked 3.2× more series than expected.

The subtle one: our port of Go's regexp/syntax used char::to_lowercase/to_uppercase to approximate Go's unicode.SimpleFold. But simple-fold orbits must be closed cycles, and the std mappings aren't — U+212A (KELVIN SIGN) folds to k, but nothing folds back to it. Any while f != c orbit walk over a negated character class became an infinite loop. If you're implementing case-insensitive matching by hand: bound your orbit walks.

Scope, honestly

EsMetrics implements what the TSBS benchmark and standard Prometheus-style usage exercises: Influx line-protocol ingestion, the Prometheus query API, the full storage engine, retention, deduplication. It does not (yet) do clustering, the agent/alerting toolchain, other ingestion protocols, or the web UI. Versioning mirrors the upstream: EsMetrics 1.146.x tracks VictoriaMetrics v1.146.0, and a scripted sync process (baselines pinned, upstream diffs auto-mapped to the Rust modules that port them) is how it stays current.

Credits and an experiment note

EsMetrics is developed by Softalink LLC, with Claude (Anthropic) as an engineering contributor — the porting blueprints, the profile-driven optimization iterations, and the benchmark harness work were done in close human-AI collaboration. We think the result — a benchmark-complete, byte-identical port of a seriously optimized production database — is an interesting data point on what that collaboration can produce, and all of the evidence is public for scrutiny.

Code: https://github.com/softalink/esmetrics
Release (Linux + Windows binaries): https://github.com/softalink/esmetrics/releases/tag/v1.146.0
Benchmarks and methodology: https://github.com/softalink/esmetrics/tree/main/benchmarks/results
Contact: info@softalink.com

EsMetrics is Apache-2.0, a derivative work of VictoriaMetrics (Copyright VictoriaMetrics, Inc.). If your organization wants commercial support, sponsored features, or benchmark validation on your hardware — we'd love to hear from you.

Bending draw.io into 2.5D: how I built isometric shearing as a plugin

Softalink LLC — Tue, 07 Jul 2026 16:58:16 +0000

The itch

Isometric diagrams make infrastructure, network, and architecture drawings instantly readable. The problem is the tooling: you either pay for a dedicated isometric app, or you hand-fake the perspective in a general tool and fight it forever. Meanwhile the general tool most of us already have open is draw.io — free, open source, offline-capable, and embedded in Confluence, GitLab, and VS Code.

So instead of leaving draw.io, I taught it to go isometric. The result is EsDraw: right-click any shape, pick a direction, and it snaps onto a 2.5D isometric plane. There's a live demo — a real self-hosted draw.io with the plugin already loaded and a sample scene open — and the code is MIT on GitHub.

Don't eyeball isometric — match a real one

The fastest way to make isometric art look "off" is to guess the angle. I didn't want guesses, so I reverse-engineered a tool people already trust for this: icograms Designer. Poking at its live DOM and SVG transforms, the model is clean:

A 2:1 isometric projection at exactly 26.565° — that's atan(0.5), the angle whose tangent is ½.
Four absolute states, not additive nudges: shear Left, Right, Clockwise, Counterclockwise. "Left then Right" lands on Right — each is a fixed transform about the shape's centre, applied fresh.
On selection, icograms draws crosshair "align lines" — a vertical axis plus two diagonals — so you can see the isometric planes. EsDraw reproduces those too.

Reducing the effect to four matrices (and their inverses) meant the whole feature could live as pure, testable math instead of a pile of special cases.

mxGraph doesn't want you to do this

draw.io is built on the mxGraph library, which renders cells to SVG but exposes no "apply an arbitrary transform to this cell and everything it owns" hook. So EsDraw monkeypatches a small set of prototypes — mxShape, mxText, mxCellRenderer, mxVertexHandler — to inject the shear at render time.

Shearing a plain box is the easy 10%. The other 90% is everything attached to the box:

Labels. mxText overrides redraw separately, so it needs its own patch — and the text has to shear about the cell's centre, not the label's bounding box, or it drifts off the shape.
Container and list children. In draw.io a container's contents are independent cells. Shearing the parent does nothing to them unless the shear resolves up the ancestor chain to the nearest sheared parent and transforms each child about that parent's centre. Same story for list items, table rows, and cells.
Fold controls. The collapse/expand chevron is drawn by a different code path (redrawControl) and has to ride along on the sheared header.
Connectors. You can't hand an edge a single transform when its two endpoints belong to shapes sheared about different centres. Instead every point on the edge follows its own terminal's shear, so arrowheads stay glued to the (now isometric) connection points.

The deep end: the selection box and resize

The thing that took the longest was the least glamorous: the dashed selection rectangle and its resize handles. Left alone, they stubbornly stay axis-aligned around a shape that clearly isn't — it looks broken. mxGraph redraws those handles through redrawHandles (not the shape's redraw), so the shear had to be applied there too, to the border, the sizers, and the rotation handle.

Then resizing had to actually work along the sheared axes. When you drag a handle, mxGraph hands you a delta in screen space; EsDraw un-shears that delta back onto the cell's own axes, then adds a centre-shift compensation so the shape resizes in place instead of sliding away as its centre moves. Getting that right is what makes dragging feel like you're resizing an isometric object rather than a flat one wearing a costume.

Architecture: pure core, thin patches

The guiding rule was simple: if it's math, it's a pure tested function; if it touches the DOM, it's a thin, replaceable patch.

The core (src/iso/*) — style parsing, the four matrices, point/delta transforms, edge-endpoint math, resize math — has no mxGraph imports and sits at 100% unit coverage via Node's built-in test runner.
The glue monkeypatches mxGraph and mostly just delegates to the core.
Browser behaviour is checked end-to-end with Playwright in a real editor.

That split is why the tricky geometry is verifiable in isolation and the integration is provable in a browser — and why every reverse-engineered finding (angles, transforms, align lines) could be written up in docs/design as the actual spec the code matches.

Try it, break it

The live demo is itself a small engineering artifact: CI fetches a pinned draw.io build, injects the plugin, and deploys it to GitHub Pages with a sample isometric scene already open — so you're clicking real draw.io, not a mock.

EsDraw is alpha (v0.1) and MIT-licensed. If you make diagrams for a living, I'd love to know where it breaks — exotic shapes, weird nesting, resize feel. Issues and stars welcome: https://github.com/softalink/esdraw.