WOAO...   la nouvelle version de SQLite (3.8.7 alpha) est 50% PLUS RAPIDE que la 3.7.17 ?   Félicitations à l'auteur.
Enfin, techniquement, cette version de SQLite utilise 50% d'instructions CPU en moins pour faire la même tâche. Ce qui est admirable.

Voilàààà ! Voilà l'idée intelligente: Plutôt que des formats binaires imbitable (coucou Microsoft) ou de l'XML-de-la-mort lourdinge (ou même - *ouch* - des documents XML zippé, coucou MSOffice/LibreOffice), ou encore YAML/jSon/le-format-de-mon-beau-frère, le développeur de ce logiciel de retouche photo a choisit SQLite comme format de sauvegarde de son application. Il s'en explique.

Personnellement, après des années à avoir développé et travaillé avec différents formats, avec des fichiers de différentes tailles, sur de multiples plateformes, ce choix devient de plus en plus évident:

• Pas de codec ou parseur maison à écrire pour votre format: On élimine ce pan de bugs potentiels.
• SQLite est un format portable: Prenez tel quel votre fichier, il est lisible partout, du PC à l'iPhone/Android (qui incluent SQLite en standard).
• Little-endian ? Big-endian ? On s'en fout: SQLite rend cela transparent.
• SQLite est lisible de tous les langages. Tout simplement. (SQLite est une lib qui peut s'intégrer statiquement dans vos applications, et elle ne fait que 230 ko)
• Le format SQLite est remarquablement stable depuis de nombreuses années (Le dernier changement de format date de 2006). C'est donc pérenne.
• SQLite peut se bouffer un fichier de 2 Go sans problème. Essayez avec un fichier XML.
• La lecture est ultra-performante (indexation), exprimée efficacement (requêtes SQL) et permet des opérations complexes (jointures, filtres, tri...). Essayez avec XML. XPath est terriblement pauvre à côté de ce que permet SQL.
• Mettre à jour un gros fichier ? Un UPDATE mettra à jour juste les parties modifiées: Vous n'avez pas tout le fichier à ré-écrire. Essayez de modifier juste une partie d'un gros fichier XML: Bonheur.
• SQLite supporte nativement le stockage de données binaires: Pas de base64 à la con en comme en XML.
• Débuguer un fichier de données ? Pas d'éditeur hexa à utiliser et d'offsets à calculer: Juste un front-end SQLite à utiliser.
• Enfin, SQLite est ACID et gère les transactions: Impossible de corrompre le fichier. Soit tout est écrit, soit rien du tout. Vos données sont toujours dans un état cohérent. Une coupure de courant en pleine sauvegarde ? Même pas mal !

C'est juste magnifique. Ces caractéristiques en font un excellent format d'enregistrement pour vos applications.
En prime, cela ouvre la possibilité de relire le fichier dans d'autres applications. Les données ne sont pas enfermées.
(La structure de la base étant incluse dans le fichier SQLite, c'est tout aussi auto-descriptif qu'un fichier XML.)

Ce n'est pas pour rien que Mozilla, Adobe, McAfee, Nokia, Bloomberg, Symbian et Oracle financent SQLite (qui est développé par une unique personne).
(oui je sais, je suis chiant avec SQLite, mais cette lib est juste magnifique par son efficacité et sa fiabilité à toute épreuve.)

EDIT: D'autres développeurs ont également fait ce choix:
http://mapbox.com/developers/mbtiles/
http://stackful-dev.com/sqlite-the-case-against-custom-application-file-formats

Pas encore eu le temps de lire, mais SQLite4 n'est pas une évolution de SQLite3: C'est quelque chose de différent et SQLite3 continuera d'exister et évoluer.

Attention: Des failles ont été trouvées dans SQLite.

Fais gaffe, Timo, il y a des bugs dans le module PDO SQLite avec les paramètres nommés:
http://sebsauvage.net/wiki/doku.php?id=php:pdo_sqlite_named_parameters_bug_workaround