(NON-WAL) Updating the database file requires EXCLUSIVE access to the database. That means that there must be no readers in order to COMMIT a transaction "write the changes to the database". This is necessarily so because the "database file" must be "static" while it is being read, just as all hell may break loose if you update a memory structure while another thread is writing (mutating) that structure. "mutexes" are used to arbitrate access to "memory structures" and "file locks" are used to arbitrate access to files. When using WAL, this is relaxed because COMMIT does not write to the database, it writes to a "write-aside" log. That means that a transaction can COMMIT (write its changes to the write-aside file) while a reader is reading the database. From time to time, however, the changes written to the "write-aside" log must be written (called a checkpoint) into the database file. However, you cannot write changes that "ought not be seen" by a current reader to the database file. Therefore, a long lasting reader can prevent the "write-aside" updates from being copied to the database. This is well explained in the referenced documentation of "write-aside logging".