Today while performing regular Drupal update and backup, I’ve realised Drupal sqlite3 database
sites/default/files/.ht.sqliteis over 440 Mb! I found it peculiar, as our website isn’t storing that much information and the size grew significantly since last time I’ve looked it up couple of months ago. I’ve decided to investigate what’s eating up so much DB space.
Investigate what’s eating up space within your sqlite3 db
There is super useful program called
sqlite3_analyzer. This program analyses your database file and reports what’s actually taking your disk space. You can download it from here (download precompiled sqlite3-tools). Note, under Linux you’ll likely need to install 32bit-libraries ie. under Ubuntu/Debian execute
sudo apt install libc6-i386 lib32stdc++6 lib32gcc1 lib32ncurses5 lib32z1
Once you have the program, simply execute
sqlite3_analyzer DB_NAME | less and the program will produce detailed report about your DB space consumption. For me it looked like that:
Can you spot how much space the actual data is taking? Yes, only 4.7% (20k pages). And what’s taking most of the space? Freelist.
Quick googling taught me, that freelist is simply empty space left after deletes or data moving. You may ask, why isn’t it cleaned up later? You see, having entire database with all tables in one file is very handy, but troublesome. Every time given table is edited, the space that is freed isn’t used, but rather marked as freelist. And those regions get cleaned up only when
vacuumcommand is issued. This should happen automatically from time-to-time if auto vacuum is enabled. I couldn’t know why isn’t it working by default with Drupal…
Reduce the size of sqlite3 DB file
Nevertheless, I’ve decided to perform
vacuummanually. Of course I’ve backed-up the db, just in case (you should always do that!). But
sqlite3 .ht.sqlite vacuum returned
Error: no such collation sequence: NOCASE_UTF8. At this point, I though maybe simple DB dump and recovery would solve my problem – after all that’s more or less what happens under the hood when you perform
sqlite3 .ht.sqlite.bck .dump > db.sql
sqlite3 .ht.sqlite < db.sql
DB recovered after dump was indeed smaller (16 Mb), but it was missing some tables (
sqlite3 .ht.sqlite .tables). Interestingly, when I’ve investigated the schema of the missing tables (
sqlite3 .ht.sqlite.bck .schema block_content), I’ve realised that all of those contain NOCASE_UTF8 in table schema. I found that really peculiar! After further googling and rather lengthy reading, I’ve realised NOCASE_UTF8 is invalid in sqlite3, but it can be replaced simply with NOCASE.
Replace DB schema directly on sqlite3 db
In the brave (and firstly stupid I though) attempt, I’ve decided just to replace wrong statements directly on the DB file using sed (
sed 's/NOCASE_UTF8/NOCASE/g' .ht.sqlite.bck > .ht.sqlite). As expected, the database file got corrupted. This is because all tables location are stored internally in the same file, so truncating some text from the DB file isn’t the wisest idea as I’ve expected. Then, I’ve decided to replace NOCASE_UTF8, but keeping the same size of the statement after replacement using white spaces. To my surprise it worked & allowed me to reduce the size of DB from 440 to 30 Mb 🙂
sed 's/NOCASE_UTF8/NOCASE /g' .ht.sqlite.bck > .ht.sqlite
sqlite3 .ht.sqlite vacuum
-rw-rw-r-- 1 lpryszcz www-data 32638976 Feb 28 13:57 .ht.sqlite
-rw-rw-r-- 1 lpryszcz www-data 451850240 Feb 28 13:45 .ht.sqlite.bck
Finally, to make sure, that there is no data missing between old and new, reduced DB, you can use
sqldiff .ht.sqlite .ht.sqlite.bck. It’ll simply report all SQL command that will transform one DB into another and nothing if DB contain identical information.
Hopefully replacing NOCASE_UTF8 with NOCASE will allow auto vacuum to proceed as expected on the Drupal DB in the future!
EDIT: The db failed after update to drupal v8.7.6
Lately, I’ve updated drupal and discovered this morning the drupal db file to be corrupted
Error: no such collation sequence: NOCASE_UTF8. This is because in the latest update, drupal rebuilt table definitions and NOCASE_UTF8 came back which causes
sqlite vacuum crashing again. The solution is very simple, just recover your db from backup and remove replace
sed -i.bck 's/NOCASE_UTF8/NOCASE /g' .ht.sqlite
Thanks for sharing this information. I would like to hear your take on running Drupal 8 site on sqlite3. Please reach out to me via email.
I’m running the website for the school I’ve started in 2016 (https://ngschool.eu/) and I’m quite happy with D8 + sqlite. It’s used for educational purposes. We don’t have much traffic but during our the courses there would be hundreds-to-thousands of requests per hour. I choose sqlite as it’s simple to backup and move the db ie during the courses we put a mirror in the local network as often the courses are in the rural areas with limited Internet bandwidth.
My impression is that sqlite back-end in drupal is made for rather small projects and prototyping, so I wouldn’t use it if you need high reliability. Nevertheless, I’m quite happy with it! But there can be some glitches or fuckups every couple of months – typically related with drupal updates that affect the table schema. I’m reporting what I can, but honestly not much response from the community – that’s why I think sqlite backend is somehow low priority for them. So it’s good to have weekly backup.
I keep entire website + db in bitbucket which is quite handy.
Hope it helps! All the best,