Optimizing a large SQLite database for reading

submited by
Style Pass
2024-10-13 20:30:05

My table structure and SELECT query was very simple. The database was going to be used for read-only access, without worrying too much about the integrity of the SQLite file (as it was re-created each day).

On my shared hosting, the query took a whopping 40 seconds to return the same results on the first run. If you re-ran the query, it took only 8 seconds on the server. On my personal laptop, that query took 198 milliseconds to return 215,000 rows.

Spoiler: eventually I decreased the runtime of the SELECT + result fetching operation from 40 seconds to 3.5 seconds with the following pragmas:

The problem turned out to be related to the slow hard-drive on my web host, and a phenomenon called a “cold start”.

As discussed on this thread, the first time SQLite runs, it stars from a “blank slate” – none of the file data has been loaded into memory yet. So SQLite depends on the operating system to load content from disk to memory.

On the second run, all of that file content from before is still resident in the operating system’s memory cache. So the subsequent queries are much faster than the first. This explains why the first time I ran a query, it took 40s, and the second only took 8s.

Leave a Comment