SQLite → 10 MB : comment ce dev a réduit sa DB de 300×
Pourquoi ça compte pour toi
Tu crées une appli ou un outil qui doit tourner sur du vieux matériel ? Cette histoire montre comment les bonnes structures de données font des miracles. Au lieu de colmater une solution bancale, il a compris le problème à la racine (recherche de préfixes dans une langue complexe) et utilisé l'outil adapté : les automates à états finis. Leçon : parfois, réinventer > continuer à optimiser un truc mal pensé dès le départ.
Ce qu'il faut retenir
- 1.Réduction de 3 GB à 10 MB en remplaçant SQLite + FTS par une structure FST (automate d'états finis)
- 2.Les FSTs compressent suffixes ET préfixes, idéal pour le finnois (langue agglutinative avec beaucoup de terminaisons communes)
- 3.Contexte : dictionnaire finnois-anglais avec recherche préfixe (tu tapes 'ka', ça te montre tous les mots commençant par 'ka')
Tu galères avec le jargon ?
Lis la version réécrite en mode débutant — toutes les idées, sans le jargon.
Pourquoi SQLite a échoué
Au départ, il y avait une approche simple : un trie (structure d'arbre pour la recherche préfixe). Ça tenait en ~60 MB, c'était rapide. Le souci ? Le finnois est une langue où un seul mot de base peut avoir 100+ formes selon les cas, pluriels, terminaisons et clitiques possibles.
Résultat : 40-60 millions de variantes à stocker. Un trie chargé en mémoire, c'était mort. Solution de contournement : balancer ça dans SQLite avec Full Text Search et garder juste le trie pour les cas courants. Ça marchait, mais un téléchargement de 3 GB ? Dingue pour un "pocket dictionary".
L'arme : les automates à états finis
Le dev a lu un article culte d'Andrew Gallant (ripgrep) sur les FSTs. L'idée clé : contrairement aux tries qui partagent les préfixes, les FSTs partagent les suffixes. Et en finnois, tu as 100 000 mots qui finissent par les mêmes formes fléchies.
Exemple simplifié : "katu" (rue) → "kadun" (génitif), "kadussa" (locatif)... Ces terminaisons récurrentes ? Les FSTs les dédupliquent radicalement.
Le résultat
- ▸Avant : 3 GB (SQLite) + latence de lecture base de données
- ▸Après : 10 MB (FST compilé en binaire statique) + recherche ultra-rapide
- ▸Bonus : la v2 du programme tient en 20 MB total (dictionnaire inclus) vs 60 MB pour la v1
Ce qui sauve tout : les données sont statiques à l'exécution. Tu compiles une fois, tu embarques le FST. C'est pas une solution universelle (mauvais choix si tes données changent souvent), mais pour un dictionnaire ? Parfait.
L'enseignement
L'auteur souligne un point philosophique : il a d'abord accepté la "mauvaise solution facile" (SQLite comme rustine) plutôt que de ne rien livrer. 9 mois plus tard, armé d'expérience, il a pu expérimenter et trouver l'approche optimale. Parfois, itérer > se paralyser à chercher la perfection dès le départ.
Et concrètement pour toi ?
Choisis ton profil — la lecture de l'article change selon qui tu es.
Pour toi, comprendre que réduire 3 GB à 10 MB, ce n'est pas juste de l'optimisation, c'est du design. C'est comme construire une maison avec le bon plan au lieu d'ajouter des cloisons. La tech avance en trouvant les bonnes structures pour les bons problèmes, pas en faisant go brrr plus fort.
Essayer maintenant
Explorer la crate FST Rust →Source
Pour aller plus loin
Cet article t'a donné envie d'approfondir ? Deux formations Noésis t'attendent :