So it's only much faster at delete, which is the least used operation? Am I reading the results correctly?

You are talking a lot about performance but using JSON everywhere. You would be much better off using protobuf or flatbuffers for this.

Are they comparing a nosql database with no search/filtering with a sql database that has those operations by any chance?

And the 279x number is for parallel deletes? If you have to do that many parallel deletes it's probably a maintenance operation and you might as well copy the remaining data out, drop the db and recreate it...

There goes any credibility.

Is your benchmark fair? No, it's really an apples to oranges comparison in many cases.

First as RocksDB is built to function as a backend to high throughput systems and has a lot of high complexity tuning parameters and background threads and is built to work on bigger workloads (with more threads obviously).

SQLite is built to be an easy option in "smaller" scenarios, in "larger" scenarios a common scenario is multiple SQLite databases (one per customer for example).

Also a dataset of 10000 entries is too small to really matter for many more complicated scenarios (one can probably hold it all in memory and just use SQLite to store things).

Does your document system handle indexing (or is there support?), an SQL user will often tune indexes (and the SQLite query handler will use properly setup indexes). I'm evaluating RocksDB in a project and from what I gathered it itself doesn't have a notion of it (but you can easily build them as separate column families).

The version of your Raspberry PI is not specified, I've used RPI's for benchmarking but the evolution of CPU's (And in later versions the peripherals like support for NVMe disks) makes each version behave differently both to each other and to "real" machines (I was able to use that to my advantage since the difference in benchmarking between the versions gave information about relative importance of code generation strategies for newer vs older CPU's).

MOST importantly, if you want to gain traction for your project you should _focus_ on the use-case that motivated you to build it (The entire MQTT thing mentioned on the GH page seems to show some other direction) rather than doing a halfbaked comparison to SQLite (that I guess you maybe used before but wasn't really suited for your use-case).

But is it web scale?

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.