I think David and Kees probably solved the conundrum for you, perhaps if I can offer some added notes in case any more readers wonder the same: A normal field/column is "persistent" storage because you will forever be able to retrieve whatever you yourself put in there. It persists. A calculated field is never "persistent" because its value is dependent on the expression/calculation/formula, mostly based on "other" columns and will change any time any of those change, thus you can never get what you put in there, only what it calculated from whatever else. Its value doesn't persist, it is derived. Now usually this calculation happens every single time the column in that row forms part of a query. So to save the incessant recalculation, there is a property/ability/permission/hint we can add in SQLite specifically that we can tell the column to, in stead of calculating EVERY time, rather calculate as soon as any data in the row is written/updated/inserted, and then remember that answer in your own cache until the next data change, so that when queried, you just give the cached/remembered answer (BUT, you certainly CAN recalculate at any point/time if you feel like it and the cached answer MUST be the same as what any such recalculation at any random time would produce, i.e: be deterministic - this is the only premise upon which such a cached system would be, and could be, allowed[1]). The name for this caching mechanism in an SQLite calculated column schema is, what seemed like a perfectly good name: "STORED". So you see the calculation never becomes "persistent" storage, just cached, and like any cache, it is fleeting and unimportant - the very moment the database engine's nose gets any whiff of a scent of change/update/rewrite to its row, the calculated value will be recalculated. This is why it doesn't get exported in a DUMP, because there is no point, upon re-import it MUST by definition be recalculated, yet it does get included in a backup because for the backup the data is not technically manipulated (no insert/update), it's just copied. I wish the SQL word used was "CACHED" in stead of "STORED", though it would probably be equally susceptible to confusion. That's why reading the documentation is such an important part of engineering. [1]: The bug discovered in SQLite during this thread is precisely because the query engine neglected to enforce this rule - something the OP transgressed (since his calculation was not deterministic and so did not yield the same result as the cached value every time) and in stead of getting an error, was allowed to do it, which ended in heartache when he dumped data and tried to re-import it, the calculated column now no longer evaluating to the same cached value as before. (The OP also made the mistake of using a dump as a backup, if he had used the backup mechanism, he would have been fine - but nowhere is this practice discouraged, it's perfectly acceptable and it would have worked just fine if the column was set up deterministically, so nobody can hold that against him.)