# Purging the config.idb after splitting frontend/backend **URL:** \ **Category:** Ignition\ **Created:** [November 3, 2021, 10:41pm UTC](https://forum.inductiveautomation.com/t/purging-the-config-idb-after-splitting-frontend-backend/52702 "2021-11-03T22:41:47Z")\ **Posts on this page:** 6\ **Page:** 2
**Author:** ![hunterdg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/hunterdg/32/67774_2.png) [@hunterdg](https://forum.inductiveautomation.com/u/hunterdg)\ **Post date:** [October 25, 2022, 3:58pm UTC](https://forum.inductiveautomation.com/t/purging-the-config-idb-after-splitting-frontend-backend/52702/21 "2022-10-25T15:58:10Z")
Thank you very much. On a related note, curious if you gentlemen have any comments relating to the worthiness of performing a "Manual" upgrade (as described above) over an auto upgrade + just dropping tables that _are empty_ in a "Manual" upgrade. Does the export/import process have more robust error checking/conversion routines than the auto upgrade process? (Do we potentially gain anything over the auto upgrade alone?) ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [October 25, 2022, 4:11pm UTC](https://forum.inductiveautomation.com/t/purging-the-config-idb-after-splitting-frontend-backend/52702/22 "2022-10-25T16:11:55Z")
At the moment, I don't think the 'manual' upgrade process you're describing is actually getting you much. We're not deleting any 'legacy' tables, so your .idb will still be inflated with these (since you ran the restore process). You could get around that two ways: 1. Export your tags and projects from the 7.9 gateway. 2. Remove your tags and projects from the 7.9 gateway. 3. Take a new .gwbk. 4. Restore the .gwbk onto the 8.X system. 5. Manually import the tags and projects OR 1. Restore the (unmodified) 7.9 gwbk onto 8.X. 2. Manually drop the offending tables from the 8.X config.idb. I would consider the second option 'safer' in terms of upgrade behavior (I don't know the current state, but at least in the past there have been issues where the upgrade does different things to tags than an import does) _and_ it's a whole lot easier. If you're not comfortable with which tables to delete or the process of deleting them, I'm sure our support department could help you. I will _also_ mention that it's entirely possible that it's just not necessary. We only start seeing issues, generally speaking, with _very_ large systems, as in systems where the `config.idb` is hundreds of megabytes or more. That mostly happens because of inefficiently stored binary data; e.g. someone has chosen to serialize very large datasets in Vision or many, _many_ image files into Image Management. If you're not actually _having_ a problem after upgrade, it's probably totally fine to just upgrade and restore the .gwbk. In some future version we'll truncate those tables for you automatically, and as a nice side benefit your .gwbk will get lighter. ---
**Author:** ![hunterdg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/hunterdg/32/67774_2.png) [@hunterdg](https://forum.inductiveautomation.com/u/hunterdg)\ **Post date:** [October 25, 2022, 4:21pm UTC](https://forum.inductiveautomation.com/t/purging-the-config-idb-after-splitting-frontend-backend/52702/23 "2022-10-25T16:21:35Z")
Thanks again for the insight. May reach out to support to confirm re proper idb tables, but I think I have a pretty good grasp with sqldiff, sqlite\_analyzer, and manual comparison. For reference, we're seeing config.idb sizes between 700MB - over 1GB after auto upgrade (in test environment), and though it's probably _fine_, we thought to investigate the cause. History is all properly stored in SQL elsewhere. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [October 25, 2022, 4:35pm UTC](https://forum.inductiveautomation.com/t/purging-the-config-idb-after-splitting-frontend-backend/52702/24 "2022-10-25T16:35:24Z")
> [@hunterdg](#): > > For reference, we're seeing config.idb sizes between 700MB - over 1GB after auto upgrade, and though it's probably _fine_, we thought to investigate the cause. I would definitely take extra steps to clean up when dealing with sqlite sizes that big - so I think you're heading down the right road. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [October 25, 2022, 10:40pm UTC](https://forum.inductiveautomation.com/t/purging-the-config-idb-after-splitting-frontend-backend/52702/25 "2022-10-25T22:40:09Z")
> [@hunterdg](#): > > between 700MB - over 1GB after auto upgrade Holy moly 🤯 out of interest, how big is the project? (tags/Windows/Templates?) ---
**Author:** ![hunterdg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/hunterdg/32/67774_2.png) [@hunterdg](https://forum.inductiveautomation.com/u/hunterdg)\ **Post date:** [October 27, 2022, 2:11pm UTC](https://forum.inductiveautomation.com/t/purging-the-config-idb-after-splitting-frontend-backend/52702/26 "2022-10-27T14:11:13Z")
🙂 While I'd be happy to answer here if it was just my project, not sure I should in this case. We're in the process of slimming it down/splitting it up. [Previous page](https://forum.inductiveautomation.com/t/purging-the-config-idb-after-splitting-frontend-backend/52702.md?page=1)