I am about to start using SQLite for maintaining in an application. For this, I am trying to determine if I should use one big database or if I should use multiple databases. After having considered different Pro's and Con's, I have determined that multiple databases is preferred.<br/> However, in some cases I will then need to be able to make a change in two databases within the same transaction - and it is especially important to me if the application crashes, in case of power failure or other scenarios where the application is not stopped correctly. [Here](https://sqlite.org/lang_attach.html) I found it described, that it should be possible (I think).<br/> The page says:<br/> *"Transactions involving multiple attached databases are atomic, assuming that the main database is not ":memory:" and the journal_mode is not WAL. If the main database is ":memory:" or if the journal_mode is WAL, then transactions continue to be atomic within each individual database file. But if the host computer crashes in the middle of a COMMIT where two or more database files are updated, some of those files might get the changes where others might not."* The first sentence tells me, that I can do this, as I am not using :memory: and I can probably do without WAL. However, it is unclear to me what the last sentence means:<br/> *"But if the host computer crashes in the middle of a COMMIT where two or more database files are updated, some of those files might get the changes where others might not."* Is this only if using :memory: or WAL or is this always the case (which sort of means the transactions using multiple database are _not_ atomic)? I assume that SQLite does something other, than just a simple commit in db1 and then in db2 as I could obviously do that myself - but I would really like to know how much I can rely on transactions involving two databases - so that either the change is made to both databases, or it it not made to any of them?