title: iOS CoreData - are there any disadvantages to enabling sqlite WAL / Write-Ahead Logging
body: <p>At the WWDC 2013 session '207: What's New in Core Data', they mention that you can enable SQLite WAL by passing an options dictionary when adding a persistent store:</p>
  
  <pre><code>@{ NSSQLitePragmasOption: @"journal_mode = WAL" }
  </code></pre>
  
  <p>(which is available on iOS4+ and will be the default for future iOS versions).</p>
  
  <p>I'm wondering whether this would generally be a good thing to enable in my app for earlier iOS versions too.</p>
  
  <p>I've consulted the <a href="http://sqlite.org/wal.html">SQLite page about write ahead logging</a> and the disadvantages they mention, most of them seem not to apply to iOS apart from:</p>
  
  <ul>
  <li>WAL might be very slightly slower (perhaps 1% or 2% slower) than the
  traditional rollback-journal approach in applications that do mostly
  reads and seldom write.</li>
  </ul>
  
  <p>pretty much all the advantages do sound like they'll probably be a benefit on iOS:</p>
  
  <ul>
  <li>WAL is significantly faster in most scenarios.</li>
  <li>WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently.</li>
  <li>Disk I/O operations tends to be more sequential using WAL.</li>
  <li>WAL uses many fewer fsync() operations and is thus less vulnerable to problems on systems where the fsync() system call is broken.</li>
  </ul>
  
  <p>I'm asuming (perhaps subject to doing some checks on my app to make sure it doesn't slow things down) that this would be a good thing to enable, but is there any downside I should watch for or any known issues?</p>