README can be improved with graphs, how to run the bench code and more info.

What about a using SQLite for test data generation?

Example:

CREATE TABLE test (
  id INTEGER PRIMARY KEY NOT NULL, 
  x REAL NOT NULL,
  y REAL NOT NULL,
  z REAL NOT NULL
);
INSERT INTO test
    WITH RECURSIVE
      cnt( id, x, y, z) AS (
      VALUES(1 , random(), random(), random()) UNION ALL 
      SELECT id+1,random(),random(), random() FROM cnt WHERE ID<1000)
    select * from cnt;

https://paulbradley.org/sqlite-test-data/
https://stackoverflow.com/questions/17931320/how-to-insert-random-data-into-a-sqlite-table-using-only-queries

Rather than creating the Vec in the inner loop, you can create it in the outer loop using with_capacity with capacity of batch size so it will not allocate in inner loop, then just reuse the Vec.

Once the execute is used, can just Vec clear to clear the items without deallocating memory. I wonder how much faster will it make.

I might be missing something here as I'm still new to async in rust, but as I understand it calling await on a future forces the runtime to serialize the execution of the program, this means that this code:

conn.execute("PRAGMA cache_size = 1000000;").await?;
conn.execute("PRAGMA locking_mode = EXCLUSIVE;").await?;
conn.execute("PRAGMA temp_store = MEMORY;").await?;

is completely synchronized and each call to the database needs to complete before the next call starts.
Now, this seems fine as this only happens once outside of the benchmark loop.

But all the code in the faker function also uses await on each async call.
For example this code :

let stmt_with_area = tx
    .prepare("INSERT INTO user VALUES (NULL, ?, ?, ?)")
    .await?;
let stmt = tx
    .prepare("INSERT INTO user VALUES (NULL, NULL, ?, ?)")
    .await?;

It seems to me that there is no reason the needs to be serialized and we should join these calls, in something like:

let (stmt_with_area, stmt ) = tokio::join!(
    tx.prepare("INSERT INTO user VALUES (NULL, ?, ?, ?)"),
    tx.prepare("INSERT INTO user VALUES (NULL, NULL, ?, ?)")
)

Finally, it also seems that we don't actually need to await the execution of the statements themselves inside the for
but that would require saving all the futures in a big vector and then joining them, which seems a bit odd and would consume a lot of memory when running the for loop for 10e6 iterations.

Current benchmarking code is a bash script hacked together. It can improved to take parameters, reduce code duplication in calling the same code

I wonder if there will be any improvement if the rust version is linked with sqlite3, with LTO enabled.

It may inline a few functions, drops many others and might improve the performance.

Rust versions are bad, could use some love in refactoring

secondly, a lot of code is repeated. applying DRY would make it better

https://www.sqlite.org/lang_attach.html