Rust all the way down.
The QuantyVerse is a stack of infrastructure software, every layer written from the ground up in Rust: wire formats and TLS, a database, a Kubernetes data store. Standard library only, no third-party dependencies. One person builds all of it, in Oberägeri, Switzerland.
Three layers. One stack.
Pull the spiral apart and you find the three pieces it is built from.
QuantyCore sits at the bottom: wire formats, HTTP/2, gRPC and TLS. QuantyDB is built on it. QuantyKube sits on top, keeps its data in QuantyDB and talks through QuantyCore's network and TLS.
Every layer is written in Rust against the standard library and other QuantyRoot crates. Nothing in between comes from anywhere else. When something breaks, there is one codebase to read and one person to ask.
QuantyCore
- The bottom layer
- Apache-2.0
- Standard library only, no
unsafe
Three foundations that should not fit together. They do, from exactly one angle. Keep scrolling.
The shared foundations for every Quanty project. Everything the layers above need to talk to the world, written here instead of pulled in from a dozen crates.
On the wire
- Protobuf
- HPACK
- HTTP/2 server, sans I/O
- gRPC
- HTTP/1.1 client
- gzip and DEFLATE
- tar
- strict JSON
In the handshake
TLS 1.3 and 1.2, client and server. Hybrid post-quantum key
exchange with X25519MLKEM768, on by default.
X.509 validation and issuance with Ed25519, P-256, P-384 and
RSA. The primitives underneath are included.
How it is checked
- published test vectors
- interop against OpenSSL and Go
- a timing test
- a fuzzer
- deliberately broken code, which has to fail
Status: unreviewed. Nobody else has reviewed it yet. Until someone has, do not rely on it for anything that matters.
QuantyCore gets its own site, core.quantyverse.net, after 17 November. Until then the source is the documentation.
QuantyDB
- The middle layer
- MIT
- alpha, 0.4.0
One database that reshapes itself into whatever you need :3
Copy-on-write all the way through. Every commit is immutable, and the database is a chain of commits, like a git repository for data. So you can ask it about the past:
get users as of 42
- Branches. Fork a database, try a change, merge it or throw it away. Free until they diverge, so every test can have its own fork and every snapshot is instant.
- Readers never block writers. A reader pins a commit and keeps it as long as it needs.
- Embedded or served. One file in your process, or a
server with
quantydb serve. - SQL that feels like SQLite, an importer that reads
.sqlitefiles directly, and its own query language, QQL. - Assets and search. Content-addressed assets with deduplication, and full-text search.
Measured
- 30 minute soak: 10,000 idle connections, 1.8 million statements
- no failure, under 10 MB
- Reads over the network
- about 20,000/s
- Writes over the network
- 9,357/s
- Full-text search against scanning 100,000 documents
- 502× faster
- Opening a database and looking up keys
- about as fast as SQLite
Status: alpha, 0.4.0. Formats may change before 1.0. The adaptive part of the promise, index suggestions and workload-aware defaults, is planned and not built.
QuantyDB gets its own site, db.quantyverse.net, after 17 November. Until then, everything is in the repository.
QuantyKube
- The top layer
- Apache-2.0
- early
Two parts of Kubernetes, rewritten in Rust.
A data store with an undo button
It speaks the etcd v3 API that the Kubernetes API server uses. etcd throws history away every five minutes. QuantyKube keeps it for a window you choose, an hour by default: list what happened to any object, read it as it was, put it back.
A restore is an ordinary write. Controllers and watches see the object come back.
A node runtime
The kubelet starts containers through it, with no shim process and no pause container per pod.
One kubectl apply, and back
An operator moves a running kubeadm cluster from etcd onto the store, and labelled nodes onto the runtime. One patch moves it back. etcd and containerd keep running, untouched.
Against etcd v3.6.15
QuantyKube etcd
Memory, idle less is better
Reads of one key per second
On disk, 500 ConfigMaps less is better
Same 2 vCPU machine for both, from docs/BENCHMARKS.md. Writes and pod start are on the benchmark page, with the full method.
Status: early. Runs in CI against an unmodified kube-apiserver, kubeadm, k3s, and SIGKILL under load. Raft for several store nodes, TLS with client certificates. Nothing has run in production.
Stacked, it is one thing.
Kube on DB on Core.
QuantyKube's store keeps its data in QuantyDB. Its network and
TLS are QuantyCore's. From a kubectl request down to
the bytes on disk, every line is written in this family and can
be read on GitHub.
- kubectl apply reaches the API server. The API server talks to the store over gRPC, HTTP/2 and TLS: QuantyCore.
- QuantyKube answers with the etcd v3 API and keeps the history.
- QuantyDB keeps the data, every commit immutable.
See it move a cluster, live.
The first public demonstration.
Cloud Native Computing Switzerland Meetup,
17 November 2026, at Open Systems AG in Zurich.
A running kubeadm cluster moves onto QuantyKube live, with one
kubectl apply, and back again.
It is recorded and will be published on vshn.tv.
How far along each part is.
Said up front, so you can decide with the real picture.
- CoreunreviewedTested against vectors, OpenSSL, Go and a fuzzer, and reviewed by nobody else yet. Do not trust its TLS with anything that matters until someone has.
- DBalpha, 0.4.0File formats may change before 1.0. The adaptive features are planned, not built.
- KubeearlyRuns in CI against an unmodified kube-apiserver, kubeadm and k3s. Nothing has run in production.
Read the source.
And wind it back up.
Everything is on GitHub under QuantyRoot. Questions go straight to the person who builds it, which is the point: you speak with the person who builds.
Where to go from here
-
QuantyKube
-
QuantyDB
-
QuantyCore
Or write: contact@elchi.dev :3