Indeed,

PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;

makes tremendous difference in SQLite performance, so now it become feasible to include it into testing.
Unfortunately, numbers in my test runs look quite different from what is provided here (in relative terms, of course).
SQLite looks to be on par with Derby, meaning 4-5 times slower than H2.

It would be interesting to figure out what is the cause for such discrepancies. Are you running on SSD or spinning drive, how many cores in your laptop, what OS, JDK is used?

Mine is quad core, hyper-threaded with SSD, Linux, Oracle JDK1.8.

Strangely, the BenchB test executes 24,088 fewer statements in the SQLite run than H2

BenchB is the only test in that bunch that is actually concurrent.
If you print exceptions which are quietly swallowed now by this test, it shows:
org.sqlite.SQLiteException: [SQLITE_BUSY] The database file is locked (database is locked),
The missing statements in the count are those that failed
This tells me that SQLite is somewhat a single-connection engine, so it's really apples-to-oranges comparison.

Are you running on SSD or spinning drive, how many cores in your laptop, what OS, JDK is used?

Mine is quad core, hyper-threaded with SSD, Linux, Oracle JDK1.8.

SSD, MacOS, 8-core hyper-threaded, Adoptium JDK 17.0.2.

Running with JDK 1.8 (I included Derby to give another datapoint),

BenchB is the only test in that bunch that is actually concurrent.
If you print exceptions which are quietly swallowed now by this test, it shows:
org.sqlite.SQLiteException: [SQLITE_BUSY] The database file is locked (database is locked),
The missing statements in the count are those that failed
This tells me that SQLite is somewhat a single-connection engine, so it's really apples-to-oranges comparison.

This was very helpful! I'm not deeply familiar with SQLite, but what I found suggested that indeed, SQLite doesn't like multiple connections. It seems the recommendation is to either synchronize in Java and do all database work on a single thread, or share a single JDBC connection across multiple threads. I tried playing with SQLite busy handlers a bit, but still wasn't able to get it to play nicely with BenchB. As you said, apples to oranges.

So, I'd like to do the following:

1. Update the performance docs to reflect "2-5x slower, depending on system configuration; these are unreliable numbers; try it out on your production hardware; etc."
2. Update the performance docs to reflect that capabilities of SQLite don't match capabilities of H2, so the current benchmarks can't be used, hence no published numbers for SQLite.
3. Merge the SQLite test code, but don't activate it in the properties file. This makes it relatively easy for others to try the benchmark, but clearly BenchB makes including SQLite benchmarks pointless.

Alternatively, if the maintainers would like, I could look at updating BenchB or the test harness or something to be friendly to reusing a connection across multiple threads. For example, non-SQLite could use a unique connection per thread, while SQLite uses the same connection across threads. Or all DBs could use the same connection across threads. Or there are multiple variants of BenchB. Lots of options here, but I'm also not sure what the goal of this would be, so would definitely like some direction before starting anything like this.

@MariusVolkhart Items 1,2, and 3 are fine, of course. As far as updating BenchB, I am not sure what would be the purpose. It's known that some of those engines are single-user and therefore are failing this test, and yes, you can work around it with synchronization, and performance numbers will get worse. Results were published just to show that H2 performance is at least in the same range or better with other products. Test is composite and different aspects of the test can be tweaked (weighted differently) to emphasize various features, like concurrency, read, update, delete etc., so you mileage may vary.
I would not spend a lot of time on those improvements, but if you want to...

Docs updated, SQLite execution commented out, but support for sqlite left in place.