> Do these properties have to hold for the life of the persisted .db file, They have to hold for the duration of the existence of the index which uses that collation. A collation can change at any time that it is not in use. An index uses a collation sequence from the time it is created until the time it is dropped and during the interval the index exists the collation sequence is in use (whether or not anything is running) and the collation must not change. > For example, suppose Unicode defines a new code point, and the collation needs to sort it in the new-correct position for that now-defined code point. Is there way the collation can go through an upgrade process that is guaranteed not to break anything? Yes, there is a command for that: REINDEX > If some users had started using the code point immediately after it was defined by the Unicode folks but before the collation upgrade was published, might the database file become unusable when the collation is upgraded? Yes. > Is there a good way to do that with SQLite? Yes, there is a command for that. REINDEX > Is there a way to handle a Windows version upgrade that includes locale changes without dropping and re-creating the table? Yes, there is a command for that. REINDEX > Perhaps some mechanism could allow telling "you had a valid collation before, and you have a new one now; please re-index" or even "here's the old and here's the new; please update the internal b-tree sorting accordingly." There is a command to test the integrity of an index: PRAGMA INTEGRITY_CHECK; There is a command to rebuild defective indexes: REINDEX