My experience is that this doesn’t necessarily hold true in practice. The concurrency primitives being used are different. I’ve put a war story below :) but it’s kind of beside the point.

My main point was that other DBs like PostgreSQL implement row level locking so can handle concurrent writes much better than SQLite.

As for my war story I hit on false deadlock detection problems writing to two separate tables from two processes with an fkey between them. Fun fact if it thinks there’s a deadlock SQLite will not call your busy callback. It will just immediately fail. I know the deadlocks were false positives because my solution was to move my backoff logic out of my busy handler and instead catch SQLITE_BUSY and call sleep myself. Identical backoff values but the “problem” disappeared.

You can run into problems if you have two threads handling two requests. Each of them might have a shared read-lock as they are getting data, and when they both try to update to a write-lock to do some update, one of them will be canceled (throw an exception: SQLITE_BUSY).

This seems to me like a Rails bug, it should be serializing transactions when running against SQLite.