Show HN: AnuDB– Backed on RocksDB, 279x Faster Than SQLite in Parallel Workloads

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!

The reason for using an embedded database is ease-of-deployment. Sometimes deployment size is relevant as well. Those use cases are usually oppositional - software that relies on a simple deployment usually doesn't require dozens of concurrent writers, and/or hundreds of transactions per second. Software that does usually needs a more in-depth installation anyway, or at least it's worthwhile to go the extra mile to optimize performance. Also the size of the dataset will often be orders-of-magnitude apart.

The reason for using an SQL database is that your data is structured in a way where using SQL to query it makes sense. Comparing SQL to No-SQL is pointless, unless your use case can be easily adapted to either of them, without suffering too much.

There are plenty of No-SQL embedded databases. A number of SQL embedded databases as well.

If speed, ease-of-deployment/embedded and SQL were important, I would use Firebird as an embedded database, like SQLite gets loaded into process memory. Depending on the version and feature set you include, this is also only a few MB, and even more ANSI SQL compliant than SQLite.

If you want to do comparisons, compare against other document/No-SQL databases.