In rollback-journal mode, other processes will still be able to read from the db while the INSERT statements are progressing. There is however a period during COMMIT where other processes are blocked from reading (their attempts will fail with error code SQLITE_BUSY). They are only blocked for a short time, just long enough for the INSERTing process to write and fsync the database pages which have been changed. At least, this is how it works for transactions that fit in SQLite's page cache (which is held in memory). For larger transactions, processes will be blocked from reading the db from the point that the cache spills until COMMIT finishes, which can be a much longer period than outlined above. The cache behaviour can be tweaked with the cache_size and cache_spill PRAGMAs. <https://www.sqlite.org/pragma.html#pragma_cache_size> The other thing which can cause processes to be blocked from reading for an extended period of time is if there is a long-running read transaction happening at the time a writer wants to COMMIT. The writer has to wait for the reader to finish before it can update the database, and new readers are not allowed to start in the meantime (to avoid writer starvation).