Vacuum your Firefox databases for better performance

Since Firefox 3.0, bookmarks, history and most storage is kept in SQLite databases. Also, the default history time span was raised from 9 to 90 days as it became more discoverable and useful thanks to the awesome bar, so depending on your browsing habits it could represent some pretty large databases.

Aas any other database, SQLite databases become fragmented over time and empty spaces appear all around. But, since there are no managing processes checking and optimizing the database, these factors eventually result in a performance hit. So, a good way to improve startup and some other bookmarks and history related tasks is to defragment and trim unused space from these databases.

To do this:

Step 1: get sqlite3, a single file command line SQLite database manager, for your platform (available for Linux, Windows, and Mac OS X).

Step 2: Copy the downloaded binary to your profile folder where all your .sqlite files reside.

Step 3: Close Firefox.

Step 4: From a command line prompt in your profile folder, run:

sqlite3 [SQLite database] VACUUM

replacing [SQLite database with the name of a SQLite file, like places.sqlite.

On Windows, to defragment all SQLite databases in one command, run:

for %a in (*.sqlite) do (sqlite3 %a vacuum)

I ran the script in a couple of machines resulting in a noticeable reduction of start up times after databases defragmentation:

Machine places.sqlite size before vacuum places.sqlite size after vacuum Cold startup Before Cold Startup After
Machine 1: 1 window, 20 tabs 10 MB 9 MB 11 s 8 s
Machine 2: 3 windows, 25 tabs 40 MB 27 MB 10 s 7 s

So if this is all good, why hasn’t Mozilla included this defragmenting procedure? The thing is they want to but still haven’t found the best way to do so. One of the suggestions so far has been to do it during an update: it has the advantage of been semi regular (about every six weeks), and already interrupts the user workflow (and requires the database files been released, turning Firefox off).

A good option for Windows users is IniFox, by InfoSpyware which simply packs sqlite3 and an interactive batch file that defragments all databases in your profile as described above. You will still have to download and copy, but you will avoid opening a console and repeating the steps for all the databases.

If you try this mechanism, please take some time to get your before and after times and sizes and share your results in the comments. For cold startups, you will have to restart your system to get valid results.

50 thoughts on “Vacuum your Firefox databases for better performance”

  1. BleachBit is a cleaning desktop application for Linux and Windows, which does VACUUM for Firefox profiles, too.
    Select Firefox – Vacuum and click Delete button (don’t worry, VACUUM does not delete any data):
    http://bleachbit-project.appspot.com/

    For me, startup time being a few seconds slower was not so bad, but the Awesomebar reacts so much faster, I recommend it to any regular Firefox user to VACUUM their profiles every few weeks.

  2. I don’t have the exact numbers, but I do have approximate.

    I’ve been using FF 3.1 (3.5) nightlies since alpha. My places.sqlite file was over 40MB. After vacuum it’s 2MB. My startup time went from ~10s, to ~2s.

    Incredible.

    1. Hui, if it is just a file defragmenter, you would end with a single chunk file but still tables and rows would be scattered inside it and possibly a significant amount of empty space.

      It doesn’t replace the vacuum command.

  3. My places went from 46MB to 19MB and my urlclassifier went from 31 to 26MB. I have never had any problems with Firefox’s startup speed but it might be slightly faster. But it would be from 2 seconds to less than 2 seconds…
    My places is big because I set my history to 600 days so I can always look up where I have been.

  4. Lovely, it’s just about instant loading all my saved tabs now and yea the awesomebar is much snappier :D
    places.sqlite went from 37.3MB to 33.8MB and urlclassifier3.sqlite went from 25.9MB to 23.1MB according to Nautilus.

    Hmm, should probably set up some cron jobs to automate this :)
    Raw data according to ls:
    -rwxr-x— 1 541K 2009-07-10 22:45 cookies.sqlite
    -rwxr-x— 1 340K 2009-07-10 22:53 cookies.sqlite

    -rw-r–r– 1 32K 2009-07-10 22:45 cookies.sqlite-journal
    -rw-r–r– 1 1.0K 2009-07-10 22:53 cookies.sqlite-journal

    -rwxr-x— 1 261K 2009-07-10 22:40 downloads.sqlite
    -rwxr-x— 1 23K 2009-07-10 22:54 downloads.sqlite

    -rwxr-x— 1 379K 2009-07-10 22:40 formhistory.sqlite
    -rwxr-x— 1 366K 2009-07-10 22:54 formhistory.sqlite

    -rwxr-x— 1 38M 2009-07-10 22:45 places.sqlite
    -rwxr-x— 1 34M 2009-07-10 22:58 places.sqlite

    -rw-r–r– 1 0 2009-07-10 22:45 places.sqlite-journal
    -rw-r–r– 1 1.0K 2009-07-10 22:58 places.sqlite-journal

    -rw-r–r– 1 107K 2009-06-12 21:11 stylish.sqlite
    -rw-r–r– 1 60K 2009-07-10 22:58 stylish.sqlite

    -rw-r–r– 1 154K 2009-04-09 19:59 ubiquity_ann.sqlite
    -rw-r–r– 1 151K 2009-07-10 22:59 ubiquity_ann.sqlite

    -rw-r–r– 1 26M 2009-07-10 22:30 urlclassifier3.sqlite
    -rw-r–r– 1 24M 2009-07-10 22:59 urlclassifier3.sqlite

    -rw-r–r– 1 4.0K 2009-07-06 22:34 webappsstore.sqlite
    -rw-r–r– 1 3.0K 2009-07-10 22:59 webappsstore.sqlite

    -rwxr-x— 1 0 2008-10-26 05:57 xulmigemo.sqlite
    -rwxr-x— 1 1.0K 2009-07-10 23:00 xulmigemo.sqlite

  5. Before:

    10/07/2009 05:16 p.m. 10.658.816 brief.sqlite
    10/07/2009 04:51 p.m. 20.480 content-prefs.sqlite
    10/07/2009 04:51 p.m. 391.168 cookies.sqlite
    10/07/2009 04:41 p.m. 54.272 downloads.sqlite
    04/09/2008 10:53 a.m. 272.384 feedbar.sqlite
    10/07/2009 04:49 p.m. 71.680 formhistory.sqlite
    21/05/2009 08:07 a.m. 4.096 jetpack_ann.sqlite
    17/06/2009 11:03 a.m. 2.048 permissions.sqlite
    10/07/2009 05:19 p.m. 4.104.192 places.sqlite
    08/07/2009 03:36 p.m. 4.096 search.sqlite
    18/06/2009 03:43 p.m. 69.632 signons.sqlite
    21/07/2008 08:43 a.m. 6.419.456 urlclassifier2.sqlite
    09/07/2009 10:21 a.m. 5.120 webappsstore.sqlite

    After:

    10/07/2009 05:25 p.m. 10.214.400 brief.sqlite
    10/07/2009 05:25 p.m. 18.432 content-prefs.sqlite
    10/07/2009 05:25 p.m. 288.768 cookies.sqlite
    10/07/2009 05:25 p.m. 14.336 downloads.sqlite
    10/07/2009 05:25 p.m. 257.024 feedbar.sqlite
    10/07/2009 05:25 p.m. 30.720 formhistory.sqlite
    10/07/2009 05:25 p.m. 4.096 jetpack_ann.sqlite
    10/07/2009 05:25 p.m. 2.048 permissions.sqlite
    10/07/2009 05:25 p.m. 2.031.616 places.sqlite
    10/07/2009 05:25 p.m. 4.096 search.sqlite
    10/07/2009 05:25 p.m. 69.632 signons.sqlite
    10/07/2009 05:25 p.m. 2.190.336 urlclassifier2.sqlite
    10/07/2009 05:25 p.m. 3.072 webappsstore.sqlite

  6. In Linux:

    $ find ~/.mozilla -type f -name \*.sqlite -exec sqlite3 ‘{}’ VACUUM \;
    $ find ~/.mozilla -type f -name \*.sqlite -exec sqlite3 ‘{}’ REINDEX \;

    1. Thanks! For some reason, i had to modify to
      find ~/.mozilla -type f -name “*.sqlite” -exec sqlite3 {} VACUUM \;
      find ~/.mozilla -type f -name “*.sqlite” -exec sqlite3 {} REINDEX \;

  7. Well, I should have noted the start-up time before. I wasn’t thinking this was going to make much of a difference in that I keep my History for a very short period of time. Restart was nearly instant (plus I had done the Workaround for Firefox 3.5 slow startups on Windows tweak as well). I kinda wish there was an English build, but I could get the understanding of what the prompts were.

  8. Beautiful, downloaded the sqlite, placed in the profiles folder and ran the batch script. Firefox was instant on!

  9. With some of you guys having your databases going 40MB -> 2MB and 50MB -> 15MB….
    I also experienced something around the 40MB -> 20MB ballpark.
    And I’m starting to think Mozilla made a huge mistake by going .sqlite.

    Looking through a hugely fragmented +50MB file everytime you type something in the awesomebar is…. BAD. It’s especially bad for people on laptops with low rpm hard drives.

    Sometimes I just can’t understand the people directing Firefox’s development.

    1. There is no perfect database. Sqlite has great performance, doesn’t need a server, uses the least amount of memory and has good tools to work with it. Mozillalinks has just shown you that another speedup of sqlite is possible if you regularly use the database. Most people don’t have such big database and probably have tiny databases compared with the people that visit Mozillalinks.

      I don’t get the negative attitude towards Mozilla just because they don’t make bugfree software.

  10. I followed all the steps, taking the extra precaution of backing up my profile first… just to put my mind at ease. Like “El Guru”, I didn’t time the results. But a cold restart of FF got me back my session (three tabs left open) in a time that was much more acceptable to me than before.

    I am hoping I’ll get even better starts once I bring Firefox Preloader back into the picture. By the way, for anyone using Preloader, make sure that one is shut down too, along with Firefox itself, before you do the vacuum procedure.

    I’ll try this again in a couple of weeks, making sure to time it.

    Good tip. Thanks!

  11. I did this, my startup time was improved, but not by a huge amount. It decreased by only a second or two. This is on Windows Vista… Here’s my sql files:

    BEFORE:

    07/12/2009 07:02 AM 7,168 content-prefs.sqlite
    07/13/2009 08:23 AM 562,176 cookies.sqlite
    07/13/2009 08:18 AM 13,312 downloads.sqlite
    07/13/2009 08:14 AM 1,328,128 formhistory.sqlite
    05/11/2009 12:39 AM 2,048 permissions.sqlite
    07/13/2009 08:23 AM 20,779,008 places.sqlite
    11/11/2008 06:16 AM 5,120 ril.sqlite
    07/12/2009 08:06 PM 2,048 search.sqlite
    07/08/2009 01:31 PM 180,224 signons.sqlite
    07/13/2009 08:20 AM 97,280 twitterfox_1.8.sqlite
    05/25/2008 12:37 AM 4,998,144 urlclassifier2.sqlite
    07/12/2009 09:46 AM 6,144 webappsstore.sqlite

    AFTER:

    07/13/2009 08:26 AM 7,168 content-prefs.sqlite
    07/13/2009 08:26 AM 386,048 cookies.sqlite
    07/13/2009 08:26 AM 2,048 downloads.sqlite
    07/13/2009 08:26 AM 1,204,224 formhistory.sqlite
    07/13/2009 08:26 AM 2,048 permissions.sqlite
    07/13/2009 08:26 AM 17,858,560 places.sqlite
    07/13/2009 08:26 AM 5,120 ril.sqlite
    07/13/2009 08:26 AM 2,048 search.sqlite
    07/13/2009 08:26 AM 110,592 signons.sqlite
    07/13/2009 08:26 AM 87,040 twitterfox_1.8.sqlite
    07/13/2009 08:26 AM 2,180,096 urlclassifier2.sqlite
    07/13/2009 08:26 AM 6,144 webappsstore.sqlite

  12. I read this page only after I “vacuumed” my sqlite files (found the tip somewhere else, and was now searching for a way to automate it), so I have no exact numbers. All my sqlite files were small to begin with, except places.sqlite. It went down from over 40MB to 17MB. Startup time didn’t change much. For me FF3.5 restarts in less time than a start only for FF3.0 needed (same profile and extensions), in under 2 seconds. Since I don’t have any temporary files and history from IE, I never was affected by the slow start bug.
    But still there is one very noticeable difference: while the awesome bar took 2 or 3 seconds on first use before displaying anything, it’s instantaneous now. And by instantaneous I mean lightning fast. No lag noticeable.

  13. Dont know the times, but startup seems little faster, and awesomebar is also faster:
    Dont know y my places.sqlite is so huge.

    17.07.2009 15:33 7.168 content-prefs.sqlite
    27.07.2009 12:51 583.680 cookies.sqlite
    27.07.2009 13:11 75.776 downloads.sqlite
    27.07.2009 13:06 676.864 formhistory.sqlite
    01.04.2009 18:32 2.048 permissions.sqlite
    27.07.2009 13:12 95.453.184 places.sqlite
    20.07.2009 15:56 2.048 search.sqlite
    17.07.2009 10:02 23.552 signons.sqlite
    15.07.2009 10:54 7.168 stylish.sqlite
    17.07.2009 13:26 53.248 webappsstore.sqlite

    27.07.2009 13:13 7.168 content-prefs.sqlite
    27.07.2009 13:13 409.600 cookies.sqlite
    27.07.2009 13:13 52.224 downloads.sqlite
    27.07.2009 13:13 652.288 formhistory.sqlite
    27.07.2009 13:13 2.048 permissions.sqlite
    27.07.2009 13:14 83.148.800 places.sqlite
    27.07.2009 13:14 2.048 search.sqlite
    27.07.2009 13:14 23.552 signons.sqlite
    27.07.2009 13:14 7.168 stylish.sqlite
    27.07.2009 13:14 52.224 webappsstore.sqlite

  14. For Linux, I’ve made this script, wich verify if Firefox is running and if sqlite3 is installed. It contains some verifications and user info, but looks good for me. Just put this in /usr/bin and call it once a month:

    —————————————————————————————

    #FIREFOX-OPTIMIZE
    #!/bin/sh

    if [ `whereis sqlite3 | grep -c /` -lt 1 ]
    then
    echo ‘sqlite3 program is necessary to this script. Install it with:’;
    echo ‘\tsudo apt-get install sqlite3′;
    exit 2;
    fi

    if [ `ps aux | grep -c /usr/lib/firefox` -gt 1 ]
    then
    echo ‘Close Firefox to run this script’;
    exit 1;
    else
    echo ‘Optimizing browser database…’;
    echo ‘This can take a while…’;

    for i in ~/.mozilla/firefox*/*/*.sqlite; do
    sqlite3 $i vacuum;
    done;
    echo ‘Optimization succesfully’;
    exit 0;
    fi

    —————————————————————————————

    1. #!/bin/bash
      # http://pastebin.pl/19714

      if [ “`ps xo cmd=|grep -c “^firefox$”`” != “0” ]
      then printf “First close firefox..\n”; exit 1
      fi

      if ! sqlcmd=”`which sqlite3 2> /dev/null`”
      then printf “sqlite3: command not found..\n”; exit 1
      fi

      find ~/.mozilla/ -type f -name “*.sqlite” -exec $sqlcmd {} VACUUM \;
      find ~/.mozilla/ -type f -name “*.sqlite” -exec $sqlcmd {} REINDEX \;

  15. I did

    for i in `find /home/*/.mozilla -name \*.sqlite`; do echo $i; done

    as su to clean up all users, but it changed the ownership of one file to root (can’t remember which), then all bookmarks history etc didn’t work so had to go through and change all perms back.

    1. OK dumb ass! where I put
      do echo $i; done
      above it should read
      do sqlite3 $i vacuum; done

      That’s just what i used to check it was running on the right files.

  16. I guess I’m one of those people who doesn’t have big sqlite files for their Firefox profiles. Nevertheless, this is still a good hint to upgrade Firefox performance. I just hope we can have a more automatic vacuuming process in future Firefox releases. I believe this would be a great addition to Firefox users who dislikes going technical.

    On a side note, where can I find definitions for each sqlite files?

    Thank you.

  17. This has worked exceptionally well on both xp sp3 FF 3.5.1 and openSuSE FF 3.5.1 while the start up was slow. So what? The really annoying part was the thing being slow to respond to cursor, google search bar and just about anything else one could imagine.

    Cleaning out the temp folders did NOTHING.

    Might I suggest a Tools->extensions that performs sqlite3 vacuum. Then no one has to think about what is the best way now. And you do it for example on a schedule like for example the FEBE extension does.

    Then it becomes the uses responsibility.

    By the way good article. I’m with Amir where do I find the meanings of not only sqlite files but use of all the mozilla files on every platform.

    I get ticked about a lot of this “hide and go seek knowledge”. Yes I do embedded kernel development and read the source. But you know I can only specialize and correct so much at a time. And for my stuff I leave ISO-9001 quality reviewed documentation.

    I’m with Mike Frysinger with this if I can help the next guy I do. So I am not complaining, I am asking how can I help the next person?

  18. so a combo of “Defraggler” and the use of Ccleaner doesn’t do the trick?
    hey..no wait..the Ccleaner does all that crap in a flash..sry, bugger me. otherwise TWEAK ya Firfox, ya brainless twats!

  19. Pingback: Web Studio 13
  20. Briljant! I came across this subject after experiencing problems with FF 3.5.3.

    It was slowing down and became none responsive.
    places.sqlite was 60 Mb after VACUUM only 500 Kb.

    If you use Total Commander you can semi automate the VACUUM proces
    TC–>Start–>Change Start Menu–>Add Item–>New Title for menu entry–> FF sqlite optimizer
    Command: X:\Pathto\Firefox\Data\profile\sqlite3.exe
    Parameters: %N VACUUM
    Click OK.
    Close FF
    Now navigate to a sqlite file go to Start and select “FF sqlite optimizer”!
    See how your file size reduces!!!!

  21. for windows this should be all you need to do (also, sqlite3.exe should be in C:\) :
    for /f %a in (‘dir /s /b C:\*.sqlite’) do (C:\sqlite3 %a vacuum)

  22. Mine went from 11mb to 10 mb … not a huge difference. but I recently cleaned out my bookmarks and ran ccleaner.

  23. Had a bit of trouble starting FF after vacuuming. Thanks to Trx64 for the script. I added a few reporting stats. Here are my results for my default profile vacuuming. The numbers come from “du -sk *.sqlite”. The places didn’t clean up much. Most of the cleanup came from urlclassifier2.

    firefox_clean.ksh: Profile: t3tdc82p.default, disk usage before: 30805
    7 content-prefs.sqlite
    302 cookies.sqlite
    11 downloads.sqlite
    98 formhistory.sqlite
    2 permissions.sqlite
    13312 places.sqlite
    2 search.sqlite
    11 signons.sqlite
    6974 urlclassifier2.sqlite
    6 webappsstore.sqlite
    firefox_clean.ksh: Profile: t3tdc82p.default, disk usage after: 25234
    7 content-prefs.sqlite
    169 cookies.sqlite
    8 downloads.sqlite
    51 formhistory.sqlite
    2 permissions.sqlite
    12740 places.sqlite
    2 search.sqlite
    11 signons.sqlite
    2181 urlclassifier2.sqlite
    6 webappsstore.sqlite
    firefox_clean.ksh: Profile: t3tdc82p.default, vacuumed: 5571
    firefox_clean.ksh: Done: Vacuum Firefox sqlite databases

    My environment has two profiles, each with a dozen addons and 10 or 18 windows, including liveHTTPheaders which may have been the cause of the startup reluctance. Another complication is that I just downloaded Firefox 3.5.4 today. When I restarted my non-default profile, it actually said “Well, this is embarrasing” and gave some instructions on how to work around the startup issue. I just clicked “restore previous session” and it worked fine. But that all made it hard to measure startup time. Shutdown time seems quicker, though.

  24. Hi
    can you tell me what the exact name of the file is for sql3 as there is not a file called exactly ( sqlite3 ) and not knowing code i dont want to make a mistake, also which section is in?

    Is it – Source Code or Precompiled Binaries For Windows?

    sqlite-amalgamation-3_6_21.zip
    (1.03 MiB)

    sqlite-amalgamation-3.6.21.tar.gz
    (1.34 MiB)

    sqlite-3_6_21-tea.tar.gz
    (1.12 MiB)

    sqlite-3.6.21.tar.gz
    (2.83 MiB)

    or these ones below?

    sqlite-3_6_21.zip
    (251.17 KiB)

    tclsqlite-3_6_21.zip
    (318.27 KiB)

    sqlitedll-3_6_21.zip
    (246.81 KiB)

    sqlite3_analyzer-3.6.1.zip
    (508.70 KiB)

    Sorry but i am not sure which one to grab as my firefox is hanging on average 30 to 40 times a day, for about 4 to 6 minutes each time while im browsing each day.
    thanks Kev

  25. Hi
    thanks ferdinand, i could not find the exact file “sqlite3″, the page had heaps
    of files all called “sglite-3- something” and I didn’t know enough about coding
    to know which actual name and file type i was supposed to use,
    the info was great, i just created a new profile instead.
    thank you ferdinand for the offer, i downloadd the plugin.
    cheers Kev

  26. My places.sqlite went from 25MB->17MB and urlclassifier3.sqlite from 55MB->25MB. Firefox startup changed from 30 seconds to 5. Excellent!
    Thanks for this tip!

  27. My results (openSuse 11.2, Firefox 3.5.6)

    before:
    7168 2009-07-26 23:53 content-prefs.sqlite
    2048 2009-12-24 01:58 cookies.sqlite
    16384 2009-12-22 13:58 downloads.sqlite
    4096 2009-12-24 01:58 formhistory.sqlite
    2048 2009-12-23 18:07 permissions.sqlite
    7860224 2009-12-24 11:30 places.sqlite
    2048 2009-12-03 20:49 search.sqlite
    11264 2009-07-18 12:10 signons.sqlite
    53555200 2009-12-24 11:30 urlclassifier3.sqlite

    after:
    7168 2009-12-24 11:32 content-prefs.sqlite
    2048 2009-12-24 11:32 cookies.sqlite
    2048 2009-12-24 11:32 downloads.sqlite
    4096 2009-12-24 11:32 formhistory.sqlite
    2048 2009-12-24 11:32 permissions.sqlite
    7278592 2009-12-24 11:32 places.sqlite
    2048 2009-12-24 11:32 search.sqlite
    11264 2009-12-24 11:32 signons.sqlite
    24039424 2009-12-24 11:33 urlclassifier3.sqlite

    No exact times, but startup now takes less than half the previous time.

  28. Wow! Yeah!

    I vacuumed the lot in particular reducing places from 10MB to 5MB and I think another big one was urlclassifier down from 6MB to 2MB.

    Start-up went from many seconds (10 – 20) to about 2 seconds!

    That’s what I’m talking about!

  29. I just delete the whole damn thing. I don’t need the URL history or the stupid “awesome” bar. I can type in most url’s myself, and those which are too long can simply be bookmarked.

  30. Great!
    Places decreased by 2/3rd.
    3.6.2 and 3.6.3 are having major cpu usage issues on Windows. Vacuum was one of the suggestions. FF is better on Linux.

    I’m putting this into cron on Linux and have it execute in the background on machine startup.

    Thanks.

  31. do note, vacuum AFTER clearing all the cache, otherwise YES you won’t see a difference.
    also if you learn SQL, you can remove items by dates, but the date are in system offset. eg cookies, are all or thing but the database has a date when it was stored. so if you want to keep recently and remove others, then try the SQL query method

Comments are closed.