Diom – Backend primitives (queue, rate limit, etc.) in one Rust binary
Hey HN, my name is Tom and I'm the founder of Svix. We've been working on Diom (https://diom.com) for the last 6 months, and I'm excited to finally share it on HN! Diom is a single Rust binary that replaces Redis, RabbitMQ, Kafka, and a lot of custom code for many common use-cases. It's open-source, self-contained, and has no external runtime dependencies. While building Svix, we had to reimplement the same backend primitives that everyone reimplements when building a service: robust caching, rate-limiting, idempotency, and more. We also constantly felt the tension between building…
What it does
In the maker’s words, at launch
Hey HN, my name is Tom and I'm the founder of Svix. We've been working on Diom (https://diom.com) for the last 6 months, and I'm excited to finally share it on HN! Diom is a single Rust binary that replaces Redis, RabbitMQ, Kafka, and a lot of custom code for many common use-cases. It's open-source, self-contained, and has no external runtime dependencies. While building Svix, we had to reimplement the same backend primitives that everyone reimplements when building a service: robust caching, rate-limiting, idempotency, and more. We also constantly felt the tension between building something custom on top of existing infra (like Redis and Postgres) and adding more dedicated services (like RabbitMQ and Kafka) which we would then need to configure, operate, back up, and maintain. This was even worse for us because Svix is open-source, so additional infrastructure meant additional burden on our customers. Six months ago we finally decided to build Diom. It's a self-contained open-source service that people can run in their infrastructure with a focus on developer experience and ease of operation. It manages its own storage using fjall (a fast LSM-tree-based storage similar to RocksDB) and therefore requires no external runtime dependencies (no redis/postgres/kafka/etc), and supports running as a single node or a highly-available Raft based cluster. The goal is for Diom to replace Redis, RabbitMQ, Kafka, and a lot of custom code for most use-cases, by offering pre-built implementations for common backend primitives. It currently supports cache, key-value, idempotency, rate-limiting, queues, and streams. We also plan on adding auth-tokens, distributed settings, feature flags, and other common components; as well as adding more functionality to existing components. The closest existing project is probably NATS with JetStream, which is also a single self-contained binary with KV, streams, and queues. One of the main differences is that Diom ships higher-level primitives like idempotency, rate limiting, and cache as first-class APIs, rather than something you build on top of KV and streams. Diom favors ease of operation over scale, so it doesn't match Kafka-level throughput or very high QPS like Redis and Dragonfly. However, most products and developers don't process multiple terabytes and billions of events per second anyway. That said, Diom can still hit high performance for its target use-cases as it implements higher-level primitives rather than basic operations. Additionally, because the primitives live in the same process as the storage, there are fewer network round-trips, which keeps latency low. It uses HTTP/2 with msgpack as the wire protocol (works fine from browsers), and ships a CLI and SDKs for Python, TypeScript, Rust, Go, and Java, with more on the way. We have Svix fully ported to Diom and continuously running tests and simulated workloads in one of our staging environments. GA (general availability) is planned for later this year, once we've moved Svix production workloads over. Repo (MIT licensed): https://github.com/svix/diom Docs: https://docs.diom.com Live playground: https://diom.com/playground I'm excited to finally share Diom, and would love to hear what everyone thinks, if you find it useful, and what other components we should build! Would also love help figuring out what to call this. We currently say "component platform," but I'm not a fan of the name.
Does the same job
all alternatives →- RARustyBox – a Busybox fork written in Rust2019 · github.com · ▲114
- FPFizzBuzz purely in Rust's trait system2020 · github.com · ▲120
- NANumax - a portable runtime for distributed appsJun 2026 · github.com · ▲6
Hi, over the past few months I've been working on this project: Numax is a small Rust runtime that does three things: it runs WebAssembly modules in a sandbox, has a built-in local key-value store, and syncs everything across nodes with CRDTs and gossip. Basically, you write a wasm module, run it on two machines, and they converge (I hope !). It's a decentralized system... I hope someone finds it interesting! There's a whitepaper I've put a lot into, and I think the code isn't bad either! I believe there's still room in this world for software that's fun and well made, and while building…
- RARiceVM – A Dis virtual machine and Limbo compiler in RustApr 2026 · ▲7
Hi, I've made a Dis virtual machine and Limbo programming language compiler (called RiceVM) in Rust. It can run Dis bytecode (for example, Inferno OS applications), compile Limbo programs, and includes a fairly complete runtime with garbage collection, concurrency features, and many of the standard modules from Inferno OS's original implementation. The project is still in an early stage, but if you're interested in learning more about RiceVM or trying it out, you can check out the links below: Project's GitHub repo: https://github.com/habedi/ricevm RiceVM documentation:…
More dev tools this month
the category →
Open-source GTM skills for technical founders
Dev tools · 29d ago · gtmcofounder.com
OpenTrailPaper is open-source bike computer firmware for the LilyGO T5S3 4.7" E-Paper PRO. It supports offline maps, GPX routes, FIT recording and Bluetooth sensors.
Dev tools · 1d ago · opentrailpaper.com
Launched alongside, May 2026
the whole month →
Parallel agents, diff reviewer, and multi-model comparisons
Dev tools · May 2026 · kilo.ai
- NW
Hey HN, Henry here from Cactus. We open-sourced Needle, a 26M parameter function-calling (tool use) model. It runs at 6000 tok/s prefill and 1200 tok/s decode on consumer devices. We were always frustrated by the little effort made towards building agentic models that run on budget phones, so we conducted investigations that led to an observation: agentic experiences are built upon tool calling, and massive models are overkill for it. Tool calling is fundamentally retrieval-and-assembly (match query to tool name, extract argument values, emit JSON), not reasoning. Cross-attention…
Life & fun · May 2026 · github.com
- FM
Dev tools · May 2026 · github.com