Issue 455749  is about the chickens coming home to roost on the SQLITE_NO_SYNC setting for ChromeOS.  The gist of it is that the filesystem does not provide the necessary app-level ordering guarantees.

Correctly-tuned SQLite WAL mode _should_ provide most of the fsync-related gains of SQLITE_NO_SYNC, in a safe manner.  "WAL" stands for Write Ahead Log.  The gist of it is that in WAL mode, SQLite will write modified blocks to a -wal file, with per-transaction checksum.  Multiple transactions are written to the -wal file.  On startup, the -wal file is read, and only the correctly-checksummed transactions are considered valid.  Periodically the -wal file is checkpointed to the main database file, which invokes something like the non-wal fsync dance.  Basically, using WAL provides a knob for tuning the fsync frequency at the expense of disk space, and the goal should probably be to reduce the fsync frequency by an order of magnitude or so with only a modest increase in disk footprint.

This means that ACID "durability" is relaxed in case of certain kinds of crashes, which I believe is sufficient for most Chrome use cases.  Note that the kind of crash in question could currently lead to corruption on ChromeOS, so this seems like a strict improvement.