> My question is about the combination of WAL journal and threading mode: Assuming that WAL journal takes care of locks over the database (?) do I need also to manage synchronization using threading mode? > What will happen if I use WAL|NORMAL with zero multi-threading protection: SQLITE_CONFIG_SINGLETHREAD (SQLITE_THREADSAFE=0)? Threading mode has nothing whatsoever to do with journal mode. Threading mode is about protecting SHARED DATA from simultaneous update by multiple threads. If you understand multiprogramming at all, then you should already understand this. There are TWO types of data associated with the SQLite3 library. There is data associated with a "Connection" and there is data associated with an instance of the "Library" itself. The THREADING MODE controls which semaphores are used to protect this data from concurrent modification. The default mode SERIALIZED, means that there are active semaphores which will PREVENT you from multiple concurrent updates of data associated with the "Connection". Setting MULTITHREADED turns this protection off. This does not mean that you can now have multiple concurrent updating of the "Connection" associated data, it means that if you attempt to do so, the SQLite3 library will not protect you and instead all hell will break loose. However, for both SERIALIZED and MULTITHREAD threading modes, the semaphores are still in effect which serialize access to global data structures. Setting SINGLETHREAD threading mode, IN ADDITION to disabling the access semaphores around connection data,also disables the semaphores protecting the global data structures from concurrent change. The so-called threading mode has nothing whatsoever to do with threading -- it has to do with the level of protection (NOTHING, BELT, or BELT and SUSPENDERS) that the library provides to protect itself from improper use.