> then rename it to overwrite the existing file ... This makes me think that probably my initial file tests weren't waiting for fsync, but the rename forces the

> then rename it to overwrite the existing file ... This makes me think that probably my initial file tests weren't waiting for fsync, but the rename forces the application to wait. I'm not sure. I can answer this one. This is conflating atomicity (atomic rename) with durability (fsync; whether data is guaranteed to be on disk and will survive power failure). These are two orthogonal things. When you use sqlite with default settings, it will give you both atomicity and durability. If you want to get both in a file system like btrfs, you need to (1) fsync the written file, (2) do the atomic rename, (3) fsync the directory that contains the renamed file. Some file systems, like ext4, do automatic fsyncs "every couple seconds", but that is of course not something to rely on when benchmarking.