whispem

Hi! Thank you so much for sharing asm.fm

Yes, in minikv, I set up GitHub Actions for automated CI. Every push or PR triggers tests, lint, and various integration checks — with a typical runtime of 20–60 seconds for the core suite (thanks to Rust’s speed and caching). This means that after a commit, I get feedback almost instantly: if a job fails, I see the logs and errors within half a minute, and if there’s a fix needed, I can push a change right away.

Rapid CI is essential for catching bugs early, allowing fast iteration and a healthy contribution workflow. I sometimes use small, continuous commits (“commit, push, fix, repeat”) during intense development or when onboarding new features, and the fast CI loop helps maintain momentum and confidence in code quality.

If you’re curious about the setup, it’s all described in LEARNING.md and visible in the repo’s .github/workflows/ scripts!

minikv actually supports a fully S3-compatible API (PUT/GET/BATCH, including TTL extensions and real-time notifications). By default, the storage engine is segmented/append-only with object records in blob files, not “one file per object”. However, you can configure a backend (like the in-memory mode for dev/test, or Sled/RocksDB) and get predictable, transparent storage behavior for objects. Storing each object as an individual file isn’t the default — for durability and atomics, objects are grouped inside segment files to enable fast compaction, consistent snapshots, and better I/O performance.

If you need “one file per object” for a specific workflow, it’s possible to add a custom backend or tweak volume logic — but as you noted, most production systems move away from that model for robustness. That said, minikv’s flexible storage API makes experimentation possible if that’s what your use-case demands and you’re fine with the trade-offs.

Let me know what your usage scenario is, and I can advise on config or feature options!

Yes, I do split my working tree into separate commits whenever possible! I use interactive staging (git add -p) to split logical chunks: features, fixes, cleanups, and documentation are committed separately for clarity. Early in the project (lots of exploratory commits), some changes were more monolithic, but as minikv matured, I've prioritized clean commit history to make code review and future changes easier. Always happy to get workflow tips — I want the repo to be easy to follow for contributors!

Absolutely: for all meaningful work I prefer small, logical commits using git add -p or similar, both for history clarity and for reviewer sanity. In initial “spike” or hack sessions (see early commits :)), it’s sometimes more monolithic, but as the codebase stabilized I refactored to have tidy, atomic commit granularity. I welcome suggestions on workflow or PR polish!

There’s not an “official” image on Docker Hub yet, but the repo ships with a ready-to-use Dockerfile and a Compose cluster example. You can build with docker build . and spin up multi-node clusters trivially. Static Rust binaries make the image compact (typically ≤30MB zipped; nothing compared to MinIO :)), with no heavy runtimes. Requirements are dead simple: a recent Docker engine, any x86_64 (or ARM) host, and a few tens of MB RAM per instance at low load, scaling with data size/traffic.

I plan to push an official image (and perhaps an OCI image with scratch base) as the project matures — open to suggestions on ideal platforms/formats.

Very relevant question! The memory profile in minikv depends on usage scenario and storage backend.

- With the in-memory backend: Every value lives in RAM (with HashMap index, WAL ring buffer, TTL map, and Bloom filters). For a cluster with a few million objects, you’ll typically see a node use as little as 50–200 MB, scaling up with active dataset size and batch inflight writes;

- With RocksDB or Sled: Persistent storage keeps RAM use lower for huge sets but still caches hot keys/metadata and maintains Bloom + index snapshots (both configurable). The minimum stays light, but DB block cache, WAL write buffering, and active transaction state all add some baseline RAM (tens to a few hundreds of MB/node in practice);

- Heavy load (many concurrent clients, transactions, or CDC enabled): Buffers, Raft logs, and transaction queues scale up, but you can cap these in config (batch size, CDC buffer, WAL fsync policy, etc);

- Prometheus /metrics and admin API expose live stats, so you can observe resource use per node in production.

If you have a specific workload or dataset in mind, feel free to share it and I can benchmark or provide more precise figures!

Thanks for the feedback and for the question! A number of choices in minikv are explicitly made to explain distributed system ideas clearly, even if not always optimal for hyperscale prod environments:

- Raft + 2PC together, as above, so people can see how distributed consensus and cross-shard atomicity actually operate and interplay (with their trade-offs);

- Several subsystems are written for readability and transparency (clean error propagation, explicit structures) even if that means a few more allocations or some lost microseconds;

- The storage layer offers different backends (RocksDB, Sled, in-memory) to let users experiment and understand their behavior, not because it’s always ideal to support so many;

- Features such as CDC (Change Data Capture), admin metrics, WAL status, and even “over-promiscuous” logs are exposed for teaching/tracing/debugging, though those might be reduced or hardened in production;

- Much of the CLI/admin API exposes “how the sausage is made,” which is gold for learning but might be hidden in a SaaS-like setting;

So yes, if I targeted only hyperscale production, some internals would be simplified or streamlined, but the educational and transparency value is central to this project’s DNA.

Thank you for this sharp and detailed question! In minikv, both Raft and 2PC are purposefully implemented, which may seem “overkill” in some contexts, but it serves both education and production-grade guarantees:

- Raft is used for intra-shard strong consistency: within each "virtual shard" (256 in total), data and metadata are replicated via Raft (with leader election and log replication), not just for cluster membership;

- 2PC (Two-Phase Commit) is only used when a transaction spans multiple shards: this allows atomic, distributed writes across multiple partitions. Raft alone is not enough for atomicity here, hence the 2PC overlay;

- The design aims to illustrate real-world distributed transaction tradeoffs, not just basic data replication. It helps understand what you gain and lose with a layered model versus simpler replication like chain replication (which, as you noted, is more common for the data path in some object stores).

So yes, in a pure object store, consensus for data replication is often skipped in favor of lighter-weight methods. Here, the explicit Raft+2PC combo is an architectural choice for anyone learning, experimenting, or wanting strong, multi-shard atomicity. In a production system focused only on throughput or simple durability, some of this could absolutely be streamlined.

Thanks!

Yes! I'll check as soon as possible

No, I was helped (.md files only) by AI to rewrite but the majority of the doc is written by myself, I just asked for help from the AI for formatting for example.

I don't see the problem to be honest

Thanks a lot! I make distinct commits "every 30s" because I'm focused and I test my project. If the CI is green, I don't touch of anything. If not, I work on the project until the CI is fully green.

I had the opportunity to request a review of my first post (which was flagged) following my email to the moderators of HN. I didn’t use AI for the codebase, only for .md files & there's no problem with that. My project was reviewed by moderators, don't worry. If the codebase or architecture was AI generated this post would not have been authorized and therefore it would not have been published.

Hello! Thank you for your message. I don’t know this project, do you have a GitHub link maybe?

Yes, I know. I had the opportunity to request a review of my first post (which was flagged) following my email to the moderators of HN. After checking, the moderator told me to redo a post because indeed I was wrongly flagged by some people here.

I already said that the code was 100% handwritten but the .md files and scripts. I don't see the problem here.

Yes, .md files are authored with the help of AI tools but not the code at all. The code is 100% by me.

My work has been reviewed, don't worry about that. But it is not vibe coded at all.

I didn't use AI or any prompt with LLMs.

So you trust random comments? I know what I'm talking about.

Some people tell I used LLMs but it's not true. I learned, a lot. It was long but it works now.

I didn't use LLMs for my projects. I learned by myself.

Hi HN,

I’m Emilie (Em’ on GitHub: https://github.com/whispem). My background is in literature and linguistics – I spent most of my pre-2025 life far away from computers.

I really started programming in January 2025 through the Apple Foundation Program, where I learned Swift, UI/UX design, and how to build basic iOS apps—even though everything felt new and visual at first! That playful intro made me realize I could actually learn to code, so I kept pushing my limits.

Since October 27th, 2025, I’ve been diving deep into Rust and systems development, building projects as a way to understand storage engines, distributed systems, and even the basics like command-line tools. I was even invited to give a talk about my learning journey and beginner perspective at Epitech Marseille on December 16th, 2025, which was an amazing (and slightly terrifying) experience!

My approach is always “learn by building” – no formal CS background, just a lot of note-taking, self-challenges, reading docs, and sharing code/experience in public. If you’re curious about how a non-traditional background can be (sometimes!) an advantage for learning technical skills, or if you’re coming to Rust/systems from outside tech, I wrote down my full path and lessons learned here: https://github.com/whispem/minikv/blob/main/LEARNING.md

Always happy to connect, share tips for nontraditional learners, or just chat about the joys and headaches of learning Rust and low-level systems from scratch. You can find everything (good and bad!) on my GitHub profile.

– Em’

This script was actually written manually to automate some repeated local fixes—mainly to speed up my workflow and make sure patches were applied consistently (and safely, with backups).

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!

Thanks for pointing it out.

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.

Thanks!

minikv implements an S3-compatible API, so you can use S3 clients/tools to PUT and GET objects through its HTTP endpoints—just like a real S3 server.

However, all storage is managed locally (in-memory, RocksDB, or Sled) by minikv. It does not use AWS S3 or any cloud storage as a backend; minikv itself stores your data on local disks.

So: applications can use minikv as if it were S3, but minikv stores data locally (not in S3).

00110001 00110000 00110001 (just kidding—this project is built and maintained by a real person)