Can't agree.

I learned about BEGIN IMMEDIATE TRANSACTION.

And there's also busy_timeout.

The article also explains why/how/when things occur in detail which is valuable.

WAL mode makes those redundant. Just use WAL mode.

We all wish you were right. But alas life's not that simple.

I suggest reading the manual on the section: "Sometimes Queries Return SQLITE_BUSY In WAL Mode"

https://sqlite.org/wal.html#sometimes_queries_return_sqlite_...

Yeah, this almost never happens in practice. It’s not even worth being concerned about.

Happened all the time to me before I did some tuning Depends how much write contention you have and how long open transactions take to finish.

The list of circumstances for WAL-mode busy errors is in the doc linked by one of the posters above. It has nothing to do with transactions.

That list lists reasons queries might return busy; queries aka. reads.

Reads returning busy is rare under WAL, but WAL mode does very little for writer-writer contention.

…what? No it doesn’t. Go read the article. Every optimization listed addresses a different performance aspect of SQLite.

How does busy_timeout address a performance aspect of SQLite?

As I explain in the post, if you have multiple connections and consistent write load, the timeout will penalize older quereres and noticeably harm your long tail latency

I thought it was a pretty good list of common Rails-application-specific and sqlite3-specific knobs to turn, for newcomers to performance tuning. (Really just a guided tour though -- turn this knob to enable this particular tool for dealing with concurrency problems...)