The API approach vs. SQLite, etc. is interesting - particularly that it does not look to have very many moving parts. I'm curious about transactional semantics though. Are they 'always on' or is there API control (still haven't gone through docs completely yet, so I may answer my own question later).
Alexander from Realm here, all interactions with the database is through full ACID transactions, but it is a bit untraditional in that the interaction model is build specifically to mobile apps.
The transactions interact with the runloop, so that you are always in an up-to-date read transaction (which always give you a consistent view and never blocks, even when other threads modify the same data). To write, you have to do explicit write transactions.
So your data is always live, consistent and up-to-date without you having to do any explicit coordination (apart from the write transaction on changes) and notifications allow you to always keep your UI up-to-date with the latest changes.
For people using SQLite, it's trivial to do the same with WAL mode and a read-only transaction on the main thread (which is what you should be doing). All writes happen off the main thread, so performance is great.
