I’m releasing minikv, a distributed key-value and object store in Rust.
What is minikv? minikv is an open-source, distributed storage engine built for learning, experimentation, and self-hosted setups. It combines a strongly-consistent key-value database (Raft), S3-compatible object storage, and basic multi-tenancy. I started minikv as a learning project about distributed systems, and it grew into something production-ready and fun to extend.
Features/highlights:
- Raft consensus with automatic failover and sharding - S3-compatible HTTP API (plus REST/gRPC APIs) - Pluggable storage backends: in-memory, RocksDB, Sled - Multi-tenant: per-tenant namespaces, role-based access, quotas, and audit - Metrics (Prometheus), TLS, JWT-based API keys - Easy to deploy (single binary, works with Docker/Kubernetes)
Quick demo (single node):
git clone https://github.com/whispem/minikv.git cd minikv cargo run --release -- --config config.example.toml curl localhost:8080/health/ready # S3 upload + read curl -X PUT localhost:8080/s3/mybucket/hello -d "hi HN" curl localhost:8080/s3/mybucket/hello
Docs, cluster setup, and architecture details are in the repo. I’d love to hear feedback, questions, ideas, or your stories running distributed infra in Rust!
Repo: https://github.com/whispem/minikv Crate: https://crates.io/crates/minikv
riku_iki•2h ago
Feb 2025: first encounter with coding
oct 2025: started learning rust
Jan 2026: production grade distributed kv store with transactions, enterprise security, durability, etc
jlundberg•1h ago
It easy to forget we all started fresh and learned a lot the first few years.
On topic, this project looks nice but a bit too featureful for my minimalistic taste.
whispem•1h ago
I get the point about feature creep. I started “small,” then kept adding features as a way to learn and push my limits. My goal is to keep the design modular enough so people can use just the parts they need.
If you (or anyone else) would be interested in a stripped-down mode or a build with fewer features, I’d love to hear what that would look like to you!
Thanks again for the thoughtful feedback.
whispem•1h ago
I’ve put a lot of work into this over the past year—learning from established open source projects and carefully testing every feature to build something robust and reliable. For now, this is still a passion and learning project, but I do hope that, eventually, it can mature enough to be used in real-world production—maybe even in enterprise contexts someday.
There’s still a long way to go, and I’m definitely open to feedback and suggestions from anyone who’d like to help me improve.
riku_iki•1h ago
whispem•1h ago
All the code, architecture, logic, and design in minikv were written by me, 100% by hand. I did use AI tools only for a small part of the documentation—specifically the README, LEARNING.md, and RAM_COMMUNITY.md files—to help structure the content and improve clarity.
But for all the source code (Rust), tests, and implementation, I wrote everything myself, reviewing and designing every part.
Let me know if you want details or want to look at a specific part of the code!
the-lazy-guy•1h ago
Nice, you are the first person I have seen who cares to type in unicode arrow instead of "->" in comments.
whispem•1h ago
I like the clarity of the real arrow—it just makes flows in comments more readable for me.
Glad to see someone noticed!
the-lazy-guy•1h ago
Also your rust implementation is 100% broken which some of comments you deleted point out.
I also love this comment: https://github.com/whispem/minikv/blob/main/src/coordinator/... It is exactly what LLMs write when you ask them to implement something.
whispem•1h ago
Just to clarify: none of the Rust code, architecture, or logic in minikv was generated by AI. Every line of code was written by me personally, without copying or pasting from LLMs or any automated tools. The only places where I used AI were a few documentation files (README, LEARNING.md, RAM_COMMUNITY.md)—never for implementation.
Regarding the commit history: I tend to work locally for a while, then push larger changes once they’re solid, so it can look like big features “appear out of nowhere.” Sorry if that makes the process look less transparent.
As for the code being “100% broken”—if that were the case, minikv wouldn’t run at all! In reality, it starts up, forms clusters, and passes its integration tests. Of course, like any open source project, there are bound to be some bugs or things to improve.
If you’ve found specific places where it actually breaks or if there are unclear comments left, I’d genuinely appreciate a bug report or concrete example.
That’s the fastest way for me to make the project better. Thanks again for taking the time to look so closely at the repo.
I’m always open to fair critique and technical suggestions!
orphea•58m ago
whispem•23m ago
cannonpalms•44m ago
I'm all for using the tools available, but I don't understand lying about it.
https://github.com/whispem/minikv/blob/main/fix_ci_complete....
whispem•18m ago
The “fix_ci_complete…” script was written (by me) to patch some CI integration issues—if the style looks generic, it’s probably because it’s a standard shell script pattern. I haven’t used LLMs to write or patch any code in minikv; any fix or automation was written and debugged manually.
If there’s something specific in the script that seems suspect, I’m happy to explain or walk through it line by line.
Again, all implementation code in minikv is mine, and I’m always open to reviewing anything that looks unclear—transparency is important to me.
whispem•15m ago
The colorful output and detailed logging are just for clarity and UX; I tend to over-comment my scripts out of habit—no AI tools were involved here (nor elsewhere in the code).
But I get why it might look generic—happy to explain any section line by line if you want!
praddlebus•1h ago
whispem•1h ago
hsur8192•59m ago
whispem•53m ago