Le site communautaire Lobsters a achevé ce weekend la migration de MariaDB à SQLite, concluant un parcours commencé en 2018 qui visait d’abord PostgreSQL. Le site tourne désormais sur un VPS unique avec quatre bases de données SQLite : contenu primaire (3.8 GB), cache (1.1 GB), code (218 MB) et Rack::Attack pour le rate limiting (555 MB). CPU et mémoire en baisse, coûts divisés par deux, et le site plus réactif selon ses utilisateurs.

Ce qui t’intéresse : c’est un pattern architectural à contre-courant : tu n’as pas besoin d’un RDBMS traditionnel pour un site qui sert une communauté active. SQLite avec la bonne architecture gère des charges de production que beaucoup associent encore à des systèmes plus complexes. Pour qui construit avec des agents, c’est un cas concret de ce qu’on peut faire avec un serveur unique et SQLite, comme nous l’avons raconté le 14 juillet avec DOOMQL.

Le pattern s’applique : si ton système a plusieurs écritures concurrentes sur la même donnée, SQLite ne suffit probablement pas. Mais si tu écris sur des bases de données séparées par fonction (comme Lobsters le fait avec contenu, cache, code et rate limiting), la simplicité opérationnelle compense.

En détail

Le contexte

Lobsters avait planifié la sortie de MariaDB depuis 2018, initialement vers PostgreSQL. En 2025, ils ont plutôt décidé d’évaluer SQLite, et cette migration est allée en production ce weekend.

L’architecture

Le système tourne désormais sur un VPS unique et utilise quatre bases de données SQLite séparées, chacune avec une responsabilité :

• Contenu primaire (3.8 GB) : histoires, commentaires, votes, utilisateurs
• Cache (1.1 GB) : couche d’accélération
• Code (218 MB) : travaux asynchrones
• Rack::Attack (555 MB) : rate limiting et blocage des requêtes abusives

La séparation par fonction évite la contention sur les écritures concurrentes, la limite la plus connue de SQLite. Chaque base de données peut croître et faire un vacuum indépendamment.

Le travail derrière

La migration est documentée dans la PR #1949 de Thomas Dziedzic : 30 commits, 188 fichiers affectés, +735/-593 lignes. Elle s’appuie sur trois PR précédentes (#1705, #1871, #1924) qui avaient préparé le terrain. Le code Rails a été adapté, les tests vérifiés, le processus de déploiement réécrit.

Ce qui a changé pour les utilisateurs

Les chiffres rapportés par l’équipe :

• Utilisation CPU en baisse
• Utilisation mémoire en baisse
• Latence perçue meilleure
• Coûts opérationnels divisés par deux (une fois le VPS MariaDB éteint)

Aucun benchmark formel, mais l’effet est assez évident pour considérer la migration permanente.

Quand SQLite ne suffit pas

SQLite a un modèle de concurrence simple : un seul processus écrit à la fois sur une base de données. Si ton application a plusieurs processus qui écrivent sur la même donnée simultanément, cela devient un goulot d’étranglement. Lobsters l’évite en séparant les écritures par base de données et en exploitant le cache pour réduire la pression sur le contenu primaire.

Si ta charge a des écritures fréquentes et concurrentes sur le même dataset, PostgreSQL ou MariaDB restent de meilleurs choix. Mais si tu peux partitionner par fonction comme Lobsters, ou si tes écritures sont sérialisables, SQLite gère des charges surprenantes.

Implications pour qui construit

Cette migration est une étude de cas pour qui conçoit des systèmes qui utilisent des agents : un agent qui lit et écrit sur SQLite local peut éviter la complexité d’une base de données distante, avec latence et coûts opérationnels inférieurs. Si l’architecture sépare les responsabilités (une base pour les sessions, une pour les résultats, une pour les logs), le modèle single-writer de SQLite n’est pas une limite mais une garantie de cohérence.

Pour approfondir l’utilisation de SQLite dans des architectures agentiques, voir l’échafaudage du site statique multilingue et l’assistant d’analyse de données, tous deux construits sur SQLite.