SQLite : fichier .sqlite

SQLite est une base de données relationnelle complète tenant dans un seul fichier, sans serveur ni processus séparé à administrer : une bibliothèque qu’une application intègre directement. Cette simplicité en a fait l’une des bases de données les plus déployées au monde, présente dans la quasi-totalité des smartphones, navigateurs web et applications de bureau.

Sa signature textuelle “SQLite format 3”, terminée par un octet nul, est particulièrement fiable et directement lisible en tête de fichier.

L’extension .db, très généraliste, n’est en aucun cas exclusive à SQLite : de nombreux autres formats de base de données ou de stockage l’utilisent aussi. C’est pourquoi une identification fiable doit toujours s’appuyer sur la signature réelle du fichier plutôt que sur cette seule extension ambiguë.

Le fichier est organisé en pages de taille fixe (souvent 4 Ko), une structure interne suffisamment stable et documentée pour que le projet garantisse une compatibilité de lecture sur le très long terme, un fichier SQLite créé aujourd’hui restant lisible par les versions futures de la bibliothèque.

Le projet SQLite lui-même se distingue par un objectif explicite de support jusqu’en 2050 et par une suite de tests exceptionnellement poussée (le code de test dépasse de plusieurs ordres de grandeur la taille du code du moteur lui-même), une rigueur qui explique en partie sa présence dans des systèmes critiques où la fiabilité prime.

La plupart des applications de messagerie mobile stockent d’ailleurs l’historique complet des conversations d’un utilisateur dans une base SQLite locale sur l’appareil, un fichier unique qui explique pourquoi la sauvegarde ou la restauration d’une conversation se limite souvent à copier ce seul fichier plutôt qu’à synchroniser des milliers d’enregistrements séparés.

Deux modes de journalisation coexistent pour garantir qu’une écriture interrompue ne corrompe pas la base : le mode “rollback journal” historique, qui copie les pages modifiées dans un fichier temporaire séparé avant de les écrire réellement, et le mode WAL (Write-Ahead Logging), plus récent, qui consigne les modifications dans un fichier -wal annexe avant de les reporter dans la base principale ; ce second mode autorise des lectures concurrentes pendant qu’une écriture est en cours, une capacité que l’ancien mode ne permettait pas.

Un fichier SQLite fermé proprement peut donc en réalité se composer de plusieurs fichiers annexes sur le disque (nom.db, nom.db-wal, nom.db-shm) tant que la connexion reste ouverte ; copier uniquement le fichier .db principal pendant que l’application qui l’utilise tourne encore risque de laisser de côté des écritures récentes non encore reportées depuis le journal WAL.