SQLite dans le développement mobile : qu'est-ce que c'est et comment ça fonctionne

Qu'est-ce que SQLite ?

SQLite est une bibliothèque en langage C qui implémente un SGBD relationnel sans serveur dédié. Elle est embarquée directement dans l'application, lisant et écrivant des données dans un fichier ordinaire du système de fichiers de l'appareil. La taille de la bibliothèque est d'environ 600 Ko, ce qui fait de SQLite la base de données SQL complète la plus légère.

SQLite prend en charge la majeure partie de la norme SQL:1999, y compris JOIN, les sous-requêtes, les déclencheurs, les vues, les index et les fonctions de fenêtre. Les limitations concernent ALTER TABLE (prise en charge limitée) et les RIGHT/FULL OUTER JOIN complets. Néanmoins, pour les applications mobiles, les fonctionnalités de SQLite sont suffisantes dans 99 % des cas de stockage local.

Selon l'enquête développeurs de Stack Overflow (2025), SQLite est la base de données la plus populaire pour les solutions embarquées et occupe la troisième place en popularité parmi tous les SGBD après MySQL et PostgreSQL. Dans le développement mobile, SQLite est utilisé dans chaque application — directement ou via des wrappers.

Caractéristiques clés de SQLite

Configuration zéro — SQLite ne nécessite ni installation, ni configuration de permissions, ni création d'utilisateurs, ni démarrage de service. La bibliothèque est liée au projet et la base de données est créée en appelant une seule fonction. Cela simplifie radicalement le déploiement par rapport aux SGBD client-serveur qui nécessitent l'installation du serveur, la configuration des ports et la création d'utilisateurs.

Le fichier de base de données SQLite est un fichier multiplateforme ordinaire qui peut être copié, analysé, envoyé sur le réseau ou restauré à partir d'une sauvegarde. Le format du fichier est stable au niveau de l'API : les fichiers SQLite 3 créés en 2004 s'ouvrent avec la version actuelle de la bibliothèque, garantissant une compatibilité des données à long terme.

Comment fonctionne SQLite : architecture et stockage

L'architecture de SQLite se compose de huit machines virtuelles : Tokenizer, Parser, Code Generator, VM, B-Tree, Pager, OS Interface et Utilities. Une requête SQL passe par le Tokenizer (division en tokens), le Parser (construction d'un AST), le Code Generator (conversion en bytecode) et est exécutée sur la machine virtuelle, qui lit les pages de données via B-Tree et Pager.

SQLite utilise B-Tree pour stocker les tables et les index. Chaque table est stockée comme un B-Tree distinct, dont les nœuds feuilles contiennent les lignes de données. Les index sont également stockés comme des B-Trees, mais avec des clés dans les feuilles. Le Pager gère le chargement des pages (par défaut 4096 octets) du fichier vers la mémoire, assurant les transactions ACID via un journal ou WAL.

Modes de journalisation

WAL (Write-Ahead Logging) est le mode recommandé pour les applications mobiles. Les modifications sont d'abord écrites dans un fichier WAL séparé, puis transférées périodiquement dans la base de données principale. Le WAL permet de lire (données anciennes) et d'écrire (via WAL) simultanément dans la base de données, améliorant ainsi les performances des applications multithread. Le journal standard (rollback journal) bloque la lecture pendant l'écriture.

Le basculement entre les modes s'effectue avec une seule requête SQL : PRAGMA journal_mode=WAL. Pour les applications mobiles avec synchronisation en arrière-plan et un thread UI lisant simultanément des données, le WAL offre de meilleures performances et l'absence de blocages de l'interface.

SQLite vs autres bases de données dans le développement mobile

SQLite n'est pas la seule option pour le stockage local de données, mais c'est la plus polyvalente. Realm offre une vitesse plus élevée d'accès direct aux objets en mémoire, mais utilise son propre format NoSQL et a une taille de bibliothèque plus importante. Core Data sur iOS est une couche ORM au-dessus de SQLite qui ajoute la gestion de graphes d'objets et l'annulation d'opérations.

Pour la plupart des applications, SQLite reste le choix optimal grâce à ses performances prévisibles, l'absence de vendor lock-in et une stabilité éprouvée par le temps. Realm et Core Data se justifient dans les projets avec des graphes d'objets complexes, des requêtes réactives ou des exigences de synchronisation entre appareils.

Le choix entre SQLite, Realm et Core Data dépend de la plateforme, des exigences du modèle d'objets et de la stratégie de synchronisation. Pour les projets multiplateformes (KMP, Flutter), SQLite reste le seul choix universel qui fonctionne sur toutes les plateformes cibles sans modification du modèle de données.

SQLite sur Android : Room et SQLiteOpenHelper

Room est une bibliothèque d'Android Jetpack qui fournit une couche ORM sur SQLite. Room génère automatiquement des requêtes SQL à partir d'interfaces DAO annotées, valide la correction des requêtes à la compilation et prend en charge les migrations de base de données lors des changements de schéma. Room est la méthode recommandée pour travailler avec SQLite sur Android.

SQLiteOpenHelper est une API de bas niveau pour la gestion directe de SQLite sans ORM. La classe gère la création, l'ouverture et la mise à jour de la base de données. SQLiteOpenHelper est adapté aux projets avec des requêtes SQL simples ou lorsque un contrôle total sur la logique SQL sans abstraction Room est nécessaire.

Exemple d'entité et DAO pour Room

Une entité dans Room est annotée avec @Entity, et un DAO avec @Dao. Room traduit les méthodes annotées en requêtes SQL : @Insert génère INSERT, @Query génère SELECT avec le SQL spécifié. Les migrations sont ajoutées via Migration avec les versions de schéma ancienne et nouvelle spécifiées. Room valide le SQL à la compilation, éliminant les erreurs de syntaxe en production.

@Entity
data class User(
    @PrimaryKey val id: Long,
    val name: String,
    @ColumnInfo(name = "created_at")
    val createdAt: Long
)

@Dao
interface UserDao {
    @Query("SELECT * FROM user ORDER BY name ASC")
    suspend fun getAllUsers(): List<User>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertUser(user: User)

    @Query("DELETE FROM user WHERE id = :id")
    suspend fun deleteUser(id: Long)
}

Room génère automatiquement l'implémentation UserDao_Impl, qui contient des requêtes SQLite d'exécution via le RoomDatabase interne. Grâce aux coroutines (suspend), les méthodes DAO s'exécutent de manière asynchrone sur un thread d'arrière-plan sans bloquer l'UI. Les types de retour Flow dans @Query mettent automatiquement à jour le résultat lors des modifications de la table.

SQLite sur iOS : FMDB et GRDB

FMDB est un wrapper Objective-C autour de l'API C de SQLite, historiquement la première bibliothèque populaire pour iOS. Elle fournit des objets FMDatabase et FMResultSet pour exécuter des requêtes et obtenir des résultats. FMDB est simple et minimaliste, mais ne prend pas en charge les constructions spécifiques à Swift — optionnels, Codable, async/await.

GRDB est une bibliothèque Swift moderne pour travailler avec SQLite. Elle fournit une API type-safe, la prise en charge de Codable, Combine Publishers, async/await, les migrations et l'observation des changements en temps réel. GRDB est préférée pour les nouveaux projets Swift grâce à son intégration complète avec Swift Concurrency et une meilleure lisibilité du code.

Exemple GRDB en Swift

GRDB définit les tables via des classes Record conformes aux protocoles FetchableRecord et TableRecord. Les requêtes sont écrites en Swift avec une syntaxe type-safe plutôt qu'en SQL brut. GRDB prend également en charge DatabaseMigrator pour le versionnage des schémas et les migrations entre versions d'application.

struct User: Codable, FetchableRecord, TableRecord {
    var id: Int64
    var name: String
    var createdAt: Date
}

let dbPool = try DatabasePool(path: dbPath)
var migrator = DatabaseMigrator()
migrator.registerMigration("v1") { db in
    try db.create(table: "user") { t in
        t.autoIncrementedPrimaryKey("id")
        t.column("name", .text).notNull()
        t.column("createdAt", .datetime).notNull()
    }
}

let users = try await dbPool.read { db in
    try User.order(Column("name")).fetchAll(db)
}

DatabasePool utilise le mode WAL de SQLite pour la lecture concurrente. Plusieurs lecteurs peuvent accéder simultanément à la base de données pendant qu'un seul rédacteur met à jour les données via WAL. GRDB gère automatiquement les connexions et les transactions, offrant un accès thread-safe à la base de données depuis n'importe quel thread sans synchronisation manuelle.

Optimisation des performances de SQLite

Les index sont le moyen le plus efficace d'accélérer les requêtes SQLite. Un index est créé sur les colonnes utilisées dans les clauses WHERE, JOIN et ORDER BY. Pour une table de 100 000 enregistrements, la recherche par une colonne indexée prend des millisecondes au lieu de secondes. Cependant, les index ralentissent les opérations INSERT et UPDATE, leur nombre doit donc être équilibré avec la fréquence d'écriture.

L'insertion par lots (batch insert) au sein d'une seule transaction accélère radicalement le chargement massif de données. L'insertion de 1000 enregistrements un par un génère une surcharge d'environ 1 seconde. Les mêmes 1000 enregistrements dans une seule transaction prennent environ 5 à 10 millisecondes. La différence s'explique par le fait que chaque INSERT individuel crée une nouvelle transaction avec une écriture synchrone sur le disque.

PRAGMAs de performance

PRAGMA sont des commandes SQLite pour configurer le comportement de la bibliothèque. Pragmas d'optimisation clés : PRAGMA synchronous=NORMAL (réduit la fréquence des fsync), PRAGMA cache_size=-8000 (alloue 8 Mo de cache), PRAGMA temp_store=MEMORY (tables temporaires en mémoire). Pour les applications mobiles avec de grands volumes de données, la combinaison de ces pragmas accélère les requêtes de 2 à 3 fois.

Une autre optimisation importante est la précompilation des requêtes SQL (prepared statements). Si une requête est exécutée de manière répétée (par exemple, insertion de 10000 lignes), compiler le SQL une fois et réutiliser l'instruction réduit la charge CPU de 30 à 50 %. Room et GRDB mettent automatiquement en cache les prepared statements, mais lors de l'utilisation directe de l'API C de SQLite, la compilation doit être effectuée manuellement.

class UserRepository(private val db: RoomDatabase) {

    suspend fun insertBatch(users: List<User>) {
        db.withTransaction {
            users.chunked(500).forEach { batch ->
                batch.forEach { user ->
                    insertUser(user)
                }
            }
        }
    }
}

L'insertion par lots avec withTransaction garantit que toutes les opérations INSERT sont exécutées dans une seule transaction. La division en sous-lots (chunked) empêche une transaction unique de devenir trop grande, ce qui pourrait bloquer d'autres threads pendant une longue période. Pour la synchronisation en arrière-plan, une taille de sous-lot de 500 enregistrements offre l'équilibre optimal entre vitesse et réactivité de l'interface.