~/.shotwell
Shotwell 0.13.0 or later -> ~/.local/share/shotwell
Shotwell's FAQ page has much more detail and a better explanation of how to migrate to a new hard drive.
--Tom Brossman
https://wiki.gnome.org/Apps/Shotwell/FAQ Shotwell 0.12.3 and earlier ~/.shotwell Shotwell 0.13.0 or later ~/.local/share/shotwell ======================================================= Shotwell Architecture Overview: Database https://wiki.gnome.org/Apps/Shotwell/Architecture/Database Shotwell uses SQLite to manage a database holding tables for the major data structures in the system, such as photos and events. Any major data structure that must persist should be stored in the database. The general implementation strategy has been to provide thin wrapper classes that abstract out the mechanics of operating with the database. The reason for this is convenience and code reuse. The SQLite database could be ripped out and replaced with another in the future without the rest of the application being affected (although the need for this seems unlikely). It also means all the SQL statements are located in a single place, rather than spread throughout the code. These thin wrapper layers do nothing more than construct database queries and return responses. There is no caching or upper-level object construction. (That is, it returns IDs rather than objects that use those IDs for their work, i.e. PhotoID versus Photo). Note that Shotwell's design doesn't allow for more than one process to access the database. It's not that SQLite doesn't support concurrency — it does — but that if one Shotwell process alters the database the other is not notified. Shotwell caches database rows in memory for performance reasons. Therefore, if the data in the database changes out from underneath it, the cached values would be inaccurate, and when they were written, would obliterate the prior changes.