Une très bonne explication sur les 2 type de journaux de SQLite : DELETE (par défaut) et WAL (qui permet les écritures simultanées).
On peut résumer ça à : Utilisez le mode WAL (plus performant, supporte mieux les opérations simultanées, moins de fsync, écritures plus performantes sur disque (car séquentielles).
Contre-indications : Utiliser SQLite via NFS (beuark), faire des transactions réparties sur plusieurs bases SQLite.  WAL est également moins intéressant si 99% de vos opérations sont des lectures.

OH ! Je me garde cette astuce: Elle permet d'utiliser SQLite pour lancer une requête sur un fichier CSV et d'en récuperer le résultat. Le tout en une seule ligne de commande.

sqlite3 :memory: -cmd '.mode csv' -cmd '.import taxi.csv taxi' 'SELECT passenger_count, COUNT(*), AVG(total_amount) FROM taxi GROUP BY passenger_count'
This uses the special :memory: filename to open an in-memory database. Then it uses two -cmd options to turn on CSV mode and import the taxi.csv file into a table called taxi. Then it runs the SQL query.

EDIT: Voir aussi https://dinedal.github.io/textql/

Des astuces pour les performances de SQLite, en particulier quand vous faites beaucoup d'INSERT/UPDATE/DELETE.
(via https://lehollandaisvolant.net/?id=20210519124029)

Woo alors attendez: SQLite peut:
- supporter l'insertion directe de json
- avoir des colonnes virtuelles basées sur le json
- et donc permet du requêtage sur ces colonnes virtuelles.
On peut donc utiliser SQLite pour stocker du json et requêter dedans en profitant des indexes et du tri !
(via http://nicolas-delsaux.hd.free.fr/Shaarli/?chmZMQ)

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