Semurg - a CPU-native data engine built with Elixir and Rust

Quick update for anyone who saw this back in July, since a few things changed.

The site moved. semurg.io is retired. Everything is now at one.semurg.io.

Anyone can run it themselves now. Back then it was live to poke at, but closed and hosted by me. That changed. The engine is still closed source, but the installer and a full benchmark suite are now public, and the first node is free forever. You stand up a real node on your own hardware in one command, and you benchmark it against whatever you already run, with no account, no sales call, and nobody in the loop but you.

Install a node (prebuilt engine, no compiler, no Rust, no separate Erlang to set up):

Benchmark it on your own box (equal-answer gated, bit-exact, no fake numbers; it stands up each open-source incumbent from its official image and runs the same queries on the same deterministic data, and prints the losses straight next to the wins):

Here is the actual reason I am posting, though. I want your feedback to make the engine better. It is early, and the fastest way I know to uplift it is to put it in front of people who will run it on workloads I have not thought of and tell me exactly where it falls over. If you clone the suite and Semurg loses a lane on your box, that is the single most useful thing you can send me, because every one of those becomes the next thing I fix.

A couple of honest places it will lose today, so you know I mean it. The OLAP lane prints Semurg’s raw-scan loss to DuckDB straight, right next to the O(1) fold win, because a columnar warehouse is built to win that scan and I would rather show it than hide it. Where it does something the others cannot is the out-of-core graph regime: on a fixed small memory budget the in-RAM engines DNF and Semurg finishes the traversal at flat memory, which is the property I actually care about. Run it, break it, and tell me what caught you out or where it lost.

On the BEAM and Rust side from the original post: it is the same engine, still one concurrent NIF arm per physical core, dirty schedulers for the long jobs, batched crossings with only ids and offsets across the boundary, and a pure-BEAM fallback per NIF. The single-node install is just that engine packaged so you can run it without me in the loop, and watching where it breaks in other people’s hands is how it gets good.

Final updates should be pushed to the engine and the benchmark suite in days and then is ready for full testing and benchmarking.