I suggest a new type of transaction is added to SQLite (or a new behavior for DEFERRED transactions). Whenever an attempt to acquire an exclusive lock to write to a file by transaction A would fail due to the existence of other writer (with an intent to write lock) in transaction B, instead returning SQLITE_BUSY immediately, transaction A would simply release (drop) it's lock allowing transaction B to finish their jobs and new attempts to write (trying to obtain a new lock) would be done automatically by SQLite for transaction A (up to the timeout limit). "Deadlocks" would never occur! The risk of the same row being updated twice (the "retried" operation A reverting a change just made by the write in the transaction B, which was favored by A to prevent a deadlock) is minimal - and this risk exists at application level anyway, no matter which SQLite transaction method is used, in case the statements in transaction A where processed/prepared shortly before the statements sent via transaction B, but B transaction was still opened shortly before A: - application query(select) data from DB, process it, etc - application (in another thread/process) prepare data as well - the B thread/process starts it's transaction first! - the A thread/process starts it's transaction lately... If this does not make sense to you, then you could at least consider making IMMEDIATE transactions the default. The performance may be lower than DEFERRED transactions, but IMHO it mimics better how a client-server DBMS works, where SQLite handles the retries with it's own mechanism by itself no matter it takes slightly more time, leaving the DEFERRED transaction as an advanced option for those looking for increased performance at the "cost" of having to handle the retries at application level.