/2025/05/06/v2-florence-seyvos-c-patrice-normand-681a20670109b637542013.jpg?#)
/2025/05/06/000-43v36kd-681a24e5ac974754142745.jpg?#)
/2025/05/06/000-32c4366-681a35f513a42795994441.jpg?#)
/2025/05/04/etats-unis-des-chercheurs-sous-pression-est-menaces-6817c2eb45876085234095.jpg?#)
Show HN: AnuDB– Backed on RocksDB, 279x Faster Than SQLite in Parallel Workloads
We recently benchmarked AnuDB, a lightweight embedded database built on top of RocksDB, against SQLite on a Raspberry Pi. The performance difference, especially for parallel operations, was dramatic.GitHub Links:AnuDBBenchmark: https://github.com/hash-anu/AnuDBBenchmarkAnuDB (Core): https://github.com/hash-anu/AnuDBWhy Compare AnuDB and SQLite? SQLite is excellent for many embedded use cases — it’s simple, battle-tested, and extremely reliable. But it doesn't scale well when parallelism or concurrent writes are required.AnuDB, built over RocksDB, offers better concurrency out of the box. We wanted to measure the practical differences using real benchmarks on a Raspberry Pi.Benchmark Setup Platform: Raspberry Pi 2 (ARMv7)Benchmarked operations: Insert, Query, Update, Delete, ParallelAnuDB uses RocksDB and MsgPack serializationSQLite uses raw data, with WAL mode enabled for fairnessKey Results Insert:AnuDB: 448 ops/secSQLite: 838 ops/secQuery:AnuDB: 54 ops/secSQLite: 30 ops/secUpdate:AnuDB: 408 ops/secSQLite: 600 ops/secDelete:AnuDB: 555 ops/secSQLite: 1942 ops/secParallel (10 threads):AnuDB: 412 ops/secSQLite: 1.4 ops/sec (!)In the parallel case, AnuDB was over 279x faster than SQLite.Why the Huge Parallel Difference? SQLite, even with WAL mode, uses global database-level locks. It’s not designed for high-concurrency scenarios.RocksDB (used in AnuDB) supports:Fine-grained lockingConcurrent readers/writersBetter parallelism using LSM-tree architectureThis explains why AnuDB significantly outperforms SQLite under threaded workloads.Try It Yourself Clone the repo:git clone https://github.com/hash-anu/AnuDBBenchmark cd AnuDBBenchmark ./build.sh /path/to/AnuDB /path/to/sqlite ./benchmarkResults are saved to benchmark_results.csv.When to Use AnuDB Use AnuDB if:You need embedded storage with high concurrencyYou’re dealing with telemetry, sensor data, or parallel workloadsYou want something lightweight and faster than SQLite under loadStick with SQLite if:You need SQL compatibilityYou value mature ecosystem/toolingFeedback Welcome This is an early experiment. We’re actively developing AnuDB and would love feedback:Is our benchmark fair?Where could we optimize further?Would this be useful in your embedded project? Comments URL: https://news.ycombinator.com/item?id=43903414 Points: 18 # Comments: 3
We recently benchmarked AnuDB, a lightweight embedded database built on top of RocksDB, against SQLite on a Raspberry Pi. The performance difference, especially for parallel operations, was dramatic.
GitHub Links:
AnuDBBenchmark: https://github.com/hash-anu/AnuDBBenchmark
AnuDB (Core): https://github.com/hash-anu/AnuDB
Why Compare AnuDB and SQLite? SQLite is excellent for many embedded use cases — it’s simple, battle-tested, and extremely reliable. But it doesn't scale well when parallelism or concurrent writes are required.
AnuDB, built over RocksDB, offers better concurrency out of the box. We wanted to measure the practical differences using real benchmarks on a Raspberry Pi.
Benchmark Setup Platform: Raspberry Pi 2 (ARMv7)
Benchmarked operations: Insert, Query, Update, Delete, Parallel
AnuDB uses RocksDB and MsgPack serialization
SQLite uses raw data, with WAL mode enabled for fairness
Key Results Insert:
AnuDB: 448 ops/sec
SQLite: 838 ops/sec
Query:
AnuDB: 54 ops/sec
SQLite: 30 ops/sec
Update:
AnuDB: 408 ops/sec
SQLite: 600 ops/sec
Delete:
AnuDB: 555 ops/sec
SQLite: 1942 ops/sec
Parallel (10 threads):
AnuDB: 412 ops/sec
SQLite: 1.4 ops/sec (!)
In the parallel case, AnuDB was over 279x faster than SQLite.
Why the Huge Parallel Difference? SQLite, even with WAL mode, uses global database-level locks. It’s not designed for high-concurrency scenarios.
RocksDB (used in AnuDB) supports:
Fine-grained locking
Concurrent readers/writers
Better parallelism using LSM-tree architecture
This explains why AnuDB significantly outperforms SQLite under threaded workloads.
Try It Yourself Clone the repo:
git clone https://github.com/hash-anu/AnuDBBenchmark cd AnuDBBenchmark ./build.sh /path/to/AnuDB /path/to/sqlite ./benchmark
Results are saved to benchmark_results.csv.
When to Use AnuDB Use AnuDB if:
You need embedded storage with high concurrency
You’re dealing with telemetry, sensor data, or parallel workloads
You want something lightweight and faster than SQLite under load
Stick with SQLite if:
You need SQL compatibility
You value mature ecosystem/tooling
Feedback Welcome This is an early experiment. We’re actively developing AnuDB and would love feedback:
Is our benchmark fair?
Where could we optimize further?
Would this be useful in your embedded project?
Comments URL: https://news.ycombinator.com/item?id=43903414
Points: 18
# Comments: 3
