I discourage coding sqlite in Rust, Here are the reasons that sqlite developers mentioned:
- Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.
- Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages.
- Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system.
- Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries.
Rust needs a mechanism to recover gracefully from OOM errors.
- Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.
nice project, S3lite can work on all platforms? Linux/Windows/Mac? also what is the internal architecture of s3lite? As far as I know sqlite using b-tree not b+tree , what is reason behind selecting b+ tree ?
Good point — just to clarify, the "279x" number isn’t about parallel deletes. The parallel test runs a mix of operations (insert, query, update, delete) across multiple threads. Each thread works on its own document range to simulate a real-world concurrent workload (like telemetry ingestion).
SQLite (even in WAL mode) hits write lock contention under concurrency, while AnuDB (using RocksDB) handles concurrent writes better due to its design.
Also, AnuDB supports indexing via an API using RocksDB's prefix extractor, so it’s not just a key-value store — basic filtering is supported.
Appreciate the feedback — will revise the post to make this clearer!
Thanks for the thoughtful and constructive feedback — you're absolutely right that this isn't a strict apples-to-apples comparison. Our aim was to evaluate practical performance in edge workloads, especially for MQTT-style use cases on constrained devices like Raspberry Pi.
A few clarifications:
Indexing: AnuDB supports indexing via an explicit API — the user needs to define indexes manually. Internally, it's backed by RocksDB and uses a prefix extractor to optimize lookups. While it's not a full SQL-style index planner, it's efficient for our document-store model.
Parallel Writes: SQLite does well in many embedded use cases, but it struggles with highly parallel writes — even in WAL mode. RocksDB (and thus AnuDB) is built for concurrency and handles write-heavy parallel loads much better. That shows in our "Parallel" test.
Dataset Size: Agreed, 10K entries is small. We kept it modest to demonstrate behavior under low-latency edge conditions, but we’re planning larger-scale tests in follow-ups.
Hardware: The test was done on a Raspberry Pi 2 with 1GB RAM and microSD storage. Thanks for pointing out that CPU/peripheral differences could affect results — that’s something we’ll document better in future benchmarks.
Use Case Focus: You're spot on about the importance of use-case-driven evaluation. AnuDB was motivated by the need for a lightweight document database for IoT and edge scenarios with MQTT support — not as a direct SQLite replacement, but as an alternative where document flexibility and concurrent ingestion matter.
I am currently expanding the example repository for AnuDB at https://github.com/hash-anu/AnuDB/tree/main. Additional example files are being added to help you gain a comprehensive understanding of AnuDB's features and implementation patterns. Please check the repository regularly for updates.
Yes, I am using an older rocksdb version 6.29.5 that was released in 2022. The main reason for this choice is that many embedded products still rely on C++11 for application development.Additionally, it offers backward compatibility, making it a practical and stable choice for such applications.