Hi Jay,
Thank you for engaging with me on this matter. I’m developing a syllabus for an Engine Prime-specific YT channel and how the database stuff works is one of my topics. Discussing this with you will help me develop said content.
The database sizes and the fact that there are multiple aren’t a problem at all. It’s also great to hear that you have nightly DB backups. I’m not aware of any schema changes for 4.3.2, though it’s highly recommended (and sometimes required) that you use the exact same versions of Engine OS & Engine DJ. This is because if there are any schema changes, you’ll run into mismatch issues where either OS or DJ expect data in columns that may not exist and what not.
Now, let’s chat about the multiple databases. For the record, I use an external SSD to store my music (i back up to a secondary SSD using a cloning tool and my NAS).
In the Engine Ecosystem, the database architecture is very much like a (for lack of a better term) Hub and Spoke, where the hub / central DB is the Host DB and the spokes are external Music or Performance Volumes.
Terms:
- Host DB: Engine DJ stores database files in the storage volume in which your user profile resides. I like to call this the “Host DB”. The purpose of this Host DB is to be the hub for Engine to interact with any other storage media that DJs will use.
- Music Volume: This is another storage device in which a user stores music. It can be removable media or internal to the computer. If a user adds music to Engine from any Music Volume, Engine will drop database files in an
Engine Library/ 
Directory in the root of that music volume. This is why you have a database file in D:\.
- Performance Volume: These are typically removable media (USB storage, SD Cards and even internal storage to Prime devices) that you will typically export playlists too.
A topic for a further discussion is the fact that there are multiple Database files. There are database files for each use case, including importing from other DJ software, iTunes, etc..
When Engine DJ starts, it will:
- Search each connected storage for an
Engine Library/
- Setup an OS event hook so that it knows when a volume is mounted or unmounted (ejected).
For each of the conditions above, Engine DJ will, among other things, review the contents of those media and synchronize history data. This is what many see as “Aggregating data”. Engine DJ wants to make sure that it has recorded many of the changes in the external volumes to the Host DB.
Engine does not automatically sync playlists, cue points and loops that were set on Performance Volumes. The sync feature will need to be invoked.
In your use case, your Host DB will be smaller compared to your Music Volume because your Host DB volume will not have all of the track data (m.db) that your Music Volume has.
The “Backup” feature that Engine DJ has will only make a copy (back up) of the Host DB. It’s in quote because it doesn’t do exactly what its label says it does for use cases like yours and mine.
I believe “Backup” functions this way because of an oversight in developing the software that has yet to be addressed:
- It’s possible that external storage for music wasn’t possible when the “Backup” feature was developed
- The engineers assumed that most people would not use external volumes for music storage
- It could be a complete oversight.
It’s for the above reasons that you see those subfolders in your Host’s boot volume.
All of that said, if you are a little savvy with some code tooling, you can run a PRAGMA integrity_check (link) on each of the DB files to see if you can detect which is potentially corrupt. I would definitely do this on copies of the DB files.
Hope this helps.
/cc @STU-C – this is the type of detail I plan on going into with the YT videos 
