Le Hollandais Volant

Un article plutôt « contre » SQLite dans un environnement serveur (typiquement un site web).

Le principal argument pour moi est celui-ci :

Decoupling storage from compute is the default architecture because it’s a really good idea.

Avec les serveurs SQL, on peut installer le gestionnaire de base de données sur une machine et le serveur web sur une autre. C’est même l’idée de base.

Avec SQLite, on n’a pas à faire ça, mais alors une seule machine et probablement aussi un seul processus gère la totalité d’une action demandée, ce qui peut la ralentir.

Mon site tourne sur SQLite parce qu’il est léger. Je ne suis ni Facebook, ni Amazon et je n’ai pas besoin de beaucoup. Mais dès qu’on veut monter en charge, il faut scinder les tâches et pour ça SQLite ne marchera pas.

Après l’article dit bien que SQLite n’a aucun problème de fiabilité ni scalabilité : une base de données SQLite de plusieurs Go fonctionnera très bien (si elle est bien architecturée). C’est juste que SQLite est assez mauvais pour gérer des tâches en parallèle, et c’est ça qui fera qu’elle sera mise à rude épreuve dès qu’un site Web commence à avoir beaucoup de visiteurs simultanées, en particulier en écriture.

Un blog unipersonnel avec peu d’écritures concurrentes (blog, etc.) n’aura aucun problème à fonctionner sous SQLite. Même avec beaucoup de visites. Mais n’utilisez pas ça pour un forum, un tchat, un réseau social.