(Edited to retract earlier agreement and amend earlier experiment report) <b>After looking into this,</b> I <b>no longer</b> agree that your test should have either succeeded, without the complaint you posted, or should have done something else. (I would think it would have "failed" often with a flurry of "busy" messages. This I expect because, by default, there is no busy handler set by the shell. <b>The shell indicates this with a message, "Error: near line 18575: database is locked"</b>. ) With sqlite3 v3.36.0 on Ubuntu, instead of the error you report I get <code> Error: near line \#\#\#: disk I/O error </code>, repeatedly, where the line number progresses. I think this also should not happen. This will be investigated. <b>This does not happen on Ubuntu 20.04 running on a system by itself. It appears to be an artifact of running on Ubuntu [WSL](https://docs.microsoft.com/en-us/windows/wsl/about).</b> (Amendment via edit in light of Richard's post:) With this in the DB stuffing process:<code> for n in $(seq 1000000); do echo "begin immediate transaction; insert into foo values($n); commit;"; done | sqlite3 test.db </code>, I continue to get the "disk I/O error" <b>on WSL only</b>. I agree that letting SQLite defer actual transaction until the next, does-something statement, is problematic. I am investigating why, without such deferment (using "immediate") there is still an error other than SQLITE_BUSY.