Sous le coude parce que ça pourra me servir: Insérer 1 milliard de lignes dans une base SQLite en moins d'une minute.

Si on résume (extrait de l'article):

PRAGMA journal_mode = OFF;
PRAGMA synchronous = 0;
PRAGMA cache_size = 1000000;
PRAGMA locking_mode = EXCLUSIVE;
PRAGMA temp_store = MEMORY;

What do these do?
- Turning off journal_mode will result in no rollback journal, thus we cannot go back if any of the transactions fail. This disables the atomic commit and rollback capabilities of SQLite. Do not use this in production.
- By turning off synchronous, SQLite does not care about writing to disk reliably and hands off that responsibility to the OS. A write to SQLite, may not mean it is flushed to the disk. Do not use this in production.
- The cache_size specifies how many memory pages SQLite is allowed to hold in the memory. Do not set this to a high value in production.
- In EXCLUSIVE locking mode, the lock held by the SQLite connection is never released.
- Setting temp_store to MEMORY will make it behave like an in-memory database.

De bonnes raisons d'utiliser SQLite (autre que celles que j'énonce d'habitude)

Pour Postgres. Sous le coude on ne sait jamais.

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)

Sous le coude: Un client SQL multibases qui permet d'afficher directement des graphes à partir des requêtes SQL.
Ça peut être sympa pour avoir rapidement des vues sur les données sans pour autant se monter un BO.

Sous le coude: Les choses à ne pas faire dans Postgres.

Sous le coude: Quelques recommandations de configuration pour Postgres.

La faille de SQLite a été montée en épingle.
En réalité, vous n'êtes vulnérable que si :
1) vous avez activé le module recherche full text (FTS3) (qui ne fait pas partie du coeur de SQLite)
et
2) Vous exécutez du code SQL arbitraire.
Si vous êtes dans le cas 2), vous être déjà dans une énorme merde question sécurité, avec SQLite ou n'importe quelle autre base, en fait.

Pour mon boulot, après avoir pratiqué de l'Oracle et du SQL Server pendant des années, j'aborde Postgres (j'ai un gros script à adapter pour Postgres).

Je veux importer des CSV, et je découvre la commande COPY qui permet de coller directement son CSV dans le script  \o/
C'est dix fois plus pratique que les outils Oracle.

J'importe des données, erreur sur un format de date: Postgres me suggère la bonne option à utiliser \o/

Je sens que je vais aimer ce dbms  :-)

(sous le coude)