Le 11 juillet 2026, un site nommé Lobsters a fait quelque chose qui paraît contre-intuitif : il a remplacé le système de base de données payant qu’il utilisait depuis plus de dix ans (un logiciel commercial nommé MariaDB, nécessitant un serveur dédié) par une base de données entièrement gratuite — SQLite. On peut voir cette dernière comme une base de données « fichier » : pas besoin de serveur séparé, aucune facture supplémentaire, elle tourne en quelques lignes de code.
Deux jours plus tard, un lundi matin, l’un des mainteneurs a posté en interne : l’usage CPU a baissé, l’empreinte mémoire a baissé, le chargement des pages est plus fluide. Le plus important : « Une fois le serveur MariaDB complètement retiré, la facture VPS mensuelle est directement divisée par deux. »
Dans le cercle des développeurs, le fil a fait exploser les compteurs. 384 likes, 92 commentaires. Non pas parce que la technologie était spectaculaire — tout au contraire, précisément parce que l’affaire était d’une simplicité désarmante.
Sept ans d’hésitation autour de la base de données
Avant de parler de cette migration, présentons brièvement Lobsters. C’est un site de « partage de liens + discussion » pour développeurs, sorte de Hacker News plus calme et plus pointu. Les utilisateurs y partagent des articles techniques, les autres votent et commentent. Le site n’est pas immense — son fichier de base de données pèse environ 500 Mo, le trafic quotidien est absorbé par un serveur ordinaire — mais il tourne sans accroc depuis plus de dix ans.
Le problème venait de la base de données utilisée. Dans ses débuts, Lobsters a choisi MariaDB — un système de base de données commercial nécessitant un serveur indépendant. Avec le temps, l’équipe a trouvé cette solution trop lourde : un serveur de plus, c’est une facture mensuelle de plus, un point de défaillance potentiel de plus à maintenir. En août 2018, le mainteneur principal pushcx a ouvert une discussion sur GitHub intitulée « Discussion sur la migration vers PostgreSQL » — une autre base de données payante.
La discussion est restée en suspens sept ans, l’orientation glissant de PostgreSQL vers SQLite. Le vrai tournant est arrivé début 2025 : le groupe d’investissement K1 a racheté MariaDB, suscitant des doutes dans la communauté sur l’avenir à long terme de MariaDB. Parallèlement, un membre de la communauté nommé Rahul a lancé dans le fil : « Est-ce que Lobsters peut tourner sur SQLite ? »
Qu’est-ce que SQLite ? En une phrase : une base de données gratuite qui stocke toutes ses données dans un fichier local. Pas d’installation, pas de configuration, pas de serveur séparé. Elle est intégrée dans le navigateur Chrome, dans WeChat, dans chacune des applications de votre téléphone — c’est le moteur de base de données le plus déployé au monde. Mais longtemps, on a présumé par défaut qu’elle « ne convenait pas à un site web », car sa conception diffère de celle des systèmes traditionnels nécessitant un serveur indépendant (MariaDB, PostgreSQL, MySQL).
La question de Rahul a renversé ce présupposé.
Première migration : CPU à 100 %, retour en arrière d’urgence
En juin 2025, un contributeur de la communauté nommé thomas0 a officiellement pris en charge la migration. Il a consigné dans son fil un récit rare d’honnêteté : l’ensemble a nécessité trois tentatives de commit, un déploiement avorté, puis la correction de trois problèmes avant la réussite finale.
Le premier déploiement a eu lieu le 21 février 2026. thomas0 et pushcx ont eu une conversation téléphonique, établi une liste de déploiement détaillée, et tout s’est déroulé comme prévu — jusqu’à la mise en ligne du nouveau code. Le site est passé en mode lecture seule (une mesure de protection empêchant la corruption des données), mais rien qu’à traiter les requêtes de navigation des utilisateurs, tout le CPU du serveur a été plaqué à 100 %. Plantage. Les deux ont cherché la cause pendant une demi-journée sans la trouver. Décision finale : rollback.
thomas0 a écrit dans le fil : « Après cet échec, je ne me sentais pas très bien. » Car il savait d’avance que, faute d’accès à la base de production, les problèmes de performance étaient un risque — et son intuition s’est confirmée.
Rétrospectivement, le problème venait de trois endroits. Dans deux d’entre eux, SQLite effectuait un « scan de table entière » sur les deux plus grandes tables de la base — comme chercher un livre à la bibliothèque en parcourant les rayons un par un depuis le premier, sans passer par le catalogue. Quand le volume est faible, rien ne se passe ; quand il grossit, à chaque ouverture de page le serveur doit relire toute la table de bout en bout, et le CPU sature. Le troisième était un motif inefficace dit « requête N+1 » : à chaque requête d’une donnée, le programme émettait en plus N requêtes supplémentaires. La bonne méthode est de récupérer d’un coup toutes les données nécessaires.
Trois problèmes, deux dans l’écriture du SQL, un dans la logique du programme. Aucun n’était un défaut de SQLite en soi — c’est que, entre deux systèmes de base de données différents, un même code produit des efficacités d’exécution radicalement différentes.
Deuxième migration : un lundi matin paisible
Après le rollback du 21 février, thomas0 n’a mis que deux jours à soumettre la troisième correction. Que fit-il ?
D’abord, il a corrigé les deux problèmes de scan de table entière repérés au premier déploiement : il a ajouté les index appropriés aux requêtes — l’équivalent d’un catalogue de recherche rapide pour ces « grandes tables ». Pour qui connaît les bases de données, c’est le b.a.-ba ; mais dans un contexte de migration, le point clé est : sur MariaDB, ces requêtes empruntaient peut-être un autre chemin d’exécution, et n’avaient donc jamais révélé de problème de performance. Passé à SQLite, la même requête, SQLite a choisi une autre stratégie — scanner toute la table. Changer de base de données a transformé le « bon code » en « mauvais code ».
Ensuite, il a corrigé la requête N+1 : remplacé les requêtes en boucle par des requêtes par lot. Le programme ne questionne plus la base une entrée à la fois, il récupère d’un coup toutes les données nécessaires.
Troisième point, il a passé une semaine à générer localement, avec un script de sa main, la moitié du volume de données réelles de Lobsters à titre de données de test — impossible d’obtenir les vraies données de production, il a dû simuler le trafic par cette méthode. Ce script représentait en soi un effort d’ingénierie supplémentaire.
Quatrième point, par précaution, il a ajouté avant le déploiement un commutateur de « journal des requêtes lentes » : au cas où un problème de performance non détecté subsisterait, le système enregistrerait automatiquement les requêtes dépassant 100 millisecondes, facilitant un repérage rapide.
Le 11 juillet 2026, second déploiement. Cette fois, l’issue fut différente. Le site est resté stable, les courbes CPU et mémoire sont restées plates. Ils ont suivi les retours dans leur canal de chat, traité deux petits soucis, puis attendu le lundi — l’épreuve réelle du pic de trafic.
Lundi matin, tout était calme. pushcx a lâché dans le chat interne : « Nous avons eu un lundi paisible. »
Pourquoi une base de données « plus simple » est-elle en fait meilleure ?
Le côté contre-intuitif de l’histoire est ici : SQLite est bien plus « rustique » que MariaDB — pas de système de permissions utilisateur, pas de support d’écritures massives simultanées, pas d’accès réseau à distance, et bien des syntaxes de requêtes avancées ne sont pas supportées. Mais une fois mise en place par Lobsters, tout est devenu meilleur.
Trois raisons.
Première : un serveur de moins, un tas d’ennuis en moins. Dans l’architecture d’origine, le programme du site Lobsters tournait sur un serveur, et la base MariaDB sur un autre. Entre les deux machines, il fallait communication réseau, maintenance séparée, sauvegardes séparées, monitoring séparé. SQLite a transformé la base en un fichier interne au programme — les données résident sur la même machine, et sauvegarder revient à copier un fichier. Pour un site comme Lobsters, « un seul serveur suffit à absorber tout le trafic », le serveur de base de données indépendant n’est pas un atout, c’est une charge.
Deuxième : supprimer la latence. À chaque ouverture de page, le programme doit interroger la base. Dans l’architecture MariaDB, cette requête faisait l’aller-retour « programme → réseau → serveur de base → réseau → programme ». Avec SQLite, la requête devient « programme → fichier local », la variable de latence réseau est totalement éliminée. Pour un site à forte lecture et faible écriture — comme un site de partage de liens — cette accélération de la réactivité est bien réelle.
Troisième : le coût. C’est le plus tangible. Le loyer mensuel du serveur MariaDB n’est plus à payer. La facture VPS est directement divisée par deux. Ce n’est pas un vague « réduction des coûts et optimisation », c’est un chiffre en moins sur la facture.
thomas0 a aussi listé dans le fil quelques détails techniques : SQLite ne supporte pas les entiers longs non signés, d’où la nécessité de changer le type de certains champs d’ID ; les règles de collation de SQLite sont plus faibles que celles de MariaDB, ne gérant que l’insensibilité à la casse pour les caractères ASCII, pas le traitement UTF-8 complet ; il a utilisé des fonctions définies par l’utilisateur pour combler quelques fonctions de calcul manquantes à SQLite. Ces détails importent peu au lecteur ordinaire, mais ils illustrent un principe : la migration consiste fondamentalement à trouver, entre deux systèmes, un nouveau chemin permettant à toutes les fonctionnalités de continuer à opérer.
« Assez bien » et le « culte de la complexité » de l’industrie logicielle
La raison pour laquelle cette histoire mérite d’être connue d’un plus large public n’est pas technique. Elle touche une habitude profondément enracinée de l’industrie logicielle : choisir par défaut la solution « grande et complète », plutôt que la solution « suffisante ».
Lobsters a choisi MariaDB à l’origine car la pratique standard de l’époque pour faire un site était « application + serveur de base de données indépendant ». Cette architecture se justifiait il y a dix ans — les attentes de croissance étaient hautes, le trafic volatil, la base devait absorber les à-coups. Mais dix ans plus tard, l’échelle de Lobsters n’a pas fondamentalement changé. C’est toujours un site communautaire de taille moyenne, dont le trafic quotidien est soutenu par un serveur ordinaire. Pourtant ce serveur de base « pour les cas improbables » a continué de générer des frais mensuels fixes.
Ce n’est pas un cas isolé. Dans l’industrie logicielle, il existe une erreur courante nommée « optimisation prématurée » : payer par avance pour une échelle qui n’est pas encore arrivée. Une équipe de start-up de trois personnes monte d’emblée un cluster Kubernetes, une architecture microservices, une base maître-esclave — juste pour « mieux s’étendre plus tard ». Ces choix ne sont pas en soi mauvais, mais au prix d’une triple hausse : complexité opérationnelle, facture mensuelle et difficulté de débogage.
Plus profondément, l’auteur veut souligner : la « sophistication » technique et l’« adéquation » sont deux choses distinctes. Une base légère, gratuite, stockant ses données dans un fichier, est effectivement moins clinquante au tableau des fonctionnalités qu’une base commerciale. Mais si vous n’avez pas besoin de ces fonctions supplémentaires — permissions multi-utilisateurs, réplication géographique, écritures massives concurrentes —, alors ces fonctions ne sont pas des atouts, ce sont des fardeaux.
Bien sûr, cela ne signifie pas que SQLite convienne à tous les cas. thomas0 lui-même a reconnu dans la discussion avec les internautes : si le site a d’importants besoins d’écriture simultanée, nécessite que plusieurs serveurs accèdent à la même donnée, ou requiert une gestion complexe des permissions utilisateur, SQLite n’est pas le bon choix. Son modèle de concurrence est « multi-lecture, écriture unique » — plusieurs personnes lisent simultanément sans problème, mais une seule peut écrire à un instant donné. Pour une communauté comme Lobsters, « où les utilisateurs naviguent bien plus qu’ils ne postent », ce n’est pas un problème. Pour Taobao ou WeChat, ce serait un désastre.
La clé réside dans l’acte d’examiner ce dont on a réellement besoin. Ce jugement compte plus que le choix du numéro de version de la base.
Enfin
De l’ouverture de la discussion par pushcx en août 2018 à la réussite du second déploiement le 11 juillet 2026, la migration de base de données de Lobsters a traversé près de huit années. Au passage : un échec, trois corrections de code, un script de test écrit de sa main, un outil de migration de base écrit de sa main, et d’innombrables discussions et « on réessaie une fois » dans le canal de chat.
Le résultat final est si simple qu’on peut le résumer en une phrase : une communauté technique historique de plus de dix ans a remplacé sa base de données, passant d’un système commercial nécessitant un serveur indépendant à une base de fichier gratuite. La facture serveur divisée par deux. Le lundi matin était paisible.
Ce n’est pas une histoire de « disruption ». C’est une histoire de « retour à l’essentiel ».
Liens de référence
- Billet Lobsters : désormais exécuté sur SQLite (publié par thomas0)
- GitHub issue #539 : l’historique complet de la migration de MariaDB vers PostgreSQL/SQLite
- Reportage de Simon Willison : Lobsters a migré vers SQLite
- Gist de la liste de déploiement de pushcx : étapes complètes des deux déploiements
- Dépôt de code open source de Lobsters (GitHub)