I did something similar to this on android but opted for sqlite for metadata and file system for the image. The sqlite data is "master" and the file system is treated as "volatile" as it can be deleted by a user at any time.
Here were my opinions:
1) Using a combination of caching techniques (access time, etags, etc) was easier to manage with a structured store.
2) There was no perceivable latency writing to the database. This could be because of the difference in payload size writing the image to a file instead of into the table.
Some thoughts if people start out in this direction.
The author doesn't mention the size of the images that are being stored in the database, but for larger files (~>1MB), it would be interesting to see Lion's/iOS 5's new external binary data storage (-setAllowsExternalBinaryDataStorage:) for Core Data compared as well, as it seems to be pitched as a "best of both worlds" approach.
Here were my opinions: 1) Using a combination of caching techniques (access time, etags, etc) was easier to manage with a structured store.
2) There was no perceivable latency writing to the database. This could be because of the difference in payload size writing the image to a file instead of into the table.
Some thoughts if people start out in this direction.