codedump

Personally, I think SQLite is good enough, but in the current agent era, it doesn’t seem good enough anymore. For example, while I was writing semquery (https://github.com/lichuang/semquery), I kept looking for an embedded database that could simultaneously support SQL queries, vector queries, and graph database functionality. SQLite makes this a bit difficult. Maybe this Turso is worth looking into.

Hong Wang was the outlier among the four winners. She was not a traditional mathematical genius. She never participated in any mathematics competitions. Her major when she entered Peking University was not mathematics. During her master's studies in Paris, she even considered changing her major to study architecture.

Hi HN,

Recently, I've been building two open-source projects: rockraft (https://github.com/lichuang/rockraft) and coredb (https://github.com/lichuang/coredb).

coredb is a strongly consistent Key-Value database built on top of openraft and RocksDB, offering full compatibility with the Redis protocol. In my opinion, the Redis protocol has become the de facto standard in the KV storage domain, and its ecosystem value should not be confined to traditional in-memory caching. By backing it with strongly consistent persistent storage, we can unlock entirely new possibilities and application scenarios—much like how HTTP evolved from a simple web page transfer protocol into a ubiquitous communication cornerstone.

Initially, I only intended to build coredb. However, during development, I realized that the "Raft + RocksDB" architectural combination possesses tremendous general-purpose value. Recognizing that other developers might also need such a reliable underlying foundation to build their own strongly consistent storage systems, I decoupled this core logic and extracted it into an independent foundational framework: rockraft.

Wiring openraft with RocksDB and decoupling the state machine replication logic wasn't trivial. If you're curious about the nitty-gritty implementation details, the architectural decisions, and the challenges I faced along the way, I've documented the whole journey in my blog here: https://www.codedump.info/en/post/20260412-rockraft/

I would love to hear your thoughts on this architecture, the code, or my take on the Redis protocol. Any feedback, questions, or harsh critiques are highly welcome!

For now, replited has just started, the initial ideas were inspired by litestream, such as how to use sqlite wal to achieve incremental replication of sqlite data, and now the biggest difference with litestream is that because of the use of opendal, so it will be easier to support the other kind storage backends, litestream only supports s3/sftp/gcs/local fs.

In addition, after the litestream author went to fly.io, the project maintenance is very little, as far as I read down the feeling, there are still a lot of details can be optimised and polished, which need to continue to spend time later.