veilletech.frCe qui se passe
Un billet répond à « PostgreSQL for Everything » en retournant l'argument : et si SQLite suffisait ? L'auteur passe en revue les services qu'un simple fichier peut remplacer.
Ce que SQLite couvre seul
- Recherche plein texte à la place de Solr ou Elasticsearch
- Documents JSON à la place de MongoDB
- File d'attente à la place de Kafka ou RabbitMQ
- Séries temporelles à haut volume à la place de Clickhouse
- Index vectoriel pour les workflows d'IA
- Cache non persistant à la place de Redis
Pourquoi l'argument porte
L'enjeu n'est pas la performance brute — sur ce terrain les moteurs spécialisés gagnent, et l'auteur ne prétend pas le contraire. L'enjeu est le nombre de services à exploiter : chacun a sa configuration, ses sauvegardes, sa supervision, ses mises à jour et son mode de panne propre.
Un fichier unique, versionnable, copiable et sans démon supprime cette surface d'un coup. Pour une application dont la charge tient sur une machine, c'est souvent le meilleur compromis — et c'est le cas de la grande majorité des applications.
Où ça s'arrête
SQLite reste mono-écrivain. Dès que plusieurs processus écrivent en concurrence de façon soutenue, ou que la donnée dépasse ce qu'une machine peut porter, l'argument tombe. Le billet assume d'ailleurs son ton provocateur : son auteur précise qu'il aime PostgreSQL.
À quoi ça sert concrètement
C'est un bon aide-mémoire avant d'ajouter une brique à une infrastructure. La question utile n'est pas « SQLite peut-il le faire ? » mais « ai-je vraiment besoin d'un service de plus pour ça ? ».