> The default is 4KB pages these days, and you might gain a little with 8KB and 16KB at insertion time, at the expense of more IO later on updates and deletes, so there's a balance to find specific to what you are doing. I tried increasing it to 8KB, I didn't see much difference. Let me try again with 8KB and 16KB and report here. > Multi-threading won't help at all on the SQLite side. But you can of course prepare all your batches in a separate thread, and use an SPSC queue to pass those batches around to the SQLite thread, to at least get some concurrency between the SQLite code, and your own code. I tried this, but went with MPSC. The numbers are almost similar as non-threaded: ``` 34.53 real 45.11 user 4.47 sys ``` (It could be very much possible that I am doing something wrong, I am new to Rust as well. Linked tthe code at the end) > (But you probably want your queue to be fixed-size and blocking when full, to throttle the producer-side, which is going to be (much?) faster than the SQLite consumer side actually doing the IO) I used the unbounded channel, so producer won't block on it. Can you tell me what difference it would make? here is my [code](https://github.com/avinassh/fast-sqlite3-inserts/blob/master/src/bin/threaded_batched.rs).