Pourquoi SQLite est partout : la base embarquée qui gagne

Ce qu’est SQLite (et pourquoi les gens le choisissent encore)

SQLite est un petit moteur de base de données livré sous forme de bibliothèque que votre application lie — comme une fonctionnalité que vous incluez, pas comme un service que vous exécutez. Plutôt que de parler via le réseau à une machine dédiée, votre appli lit et écrit dans un seul fichier de base de données (souvent quelque chose comme app.db) sur le disque.

Cette idée de « c’est juste un fichier » explique en grande partie l’attrait. Le fichier de base contient tables, index et données, et SQLite gère les parties difficiles — requêtes, contraintes et transactions ACID — en coulisses.

Embarqué vs « serveur de base de données »

Avec une base client-serveur (pensez à PostgreSQL ou MySQL), vous :

• installez et lancez un serveur de base de données
• configurez utilisateurs, ports, sauvegardes, monitoring
• vous y connectez depuis votre application via TCP

Avec SQLite, la base s’exécute dans le processus de votre application. Il n’y a pas de serveur séparé à installer, démarrer ou maintenir. Votre appli appelle l’API SQLite, et SQLite lit/écrit le fichier local directement.

On décrit souvent SQLite comme « sans serveur ». Cela ne signifie pas qu’il vit dans le cloud sans serveurs — cela signifie que vous ne gérez pas un processus serveur de base de données séparé.

Vous l’avez probablement déjà utilisé sans le remarquer

SQLite apparaît discrètement dans de nombreux logiciels du quotidien parce qu’il est facile à distribuer et fiable :

• applications mobiles ayant besoin d’un stockage local
• applications desktop stockant paramètres, caches ou données utilisateur
• navigateurs, applications de chat et outils nécessitant un stockage structuré
• applications local-first qui continuent de fonctionner hors ligne

Beaucoup de produits choisissent SQLite car c’est un choix par défaut simple : rapide, stable et sans configuration.

Un excellent choix par défaut (avec limites)

SQLite est parfait pour de nombreuses applications mono‑utilisateur, dispositifs embarqués, prototypes devenant produits réels, et services avec une concurrence d’écriture modérée. Mais ce n’est pas la solution à tous les problèmes d’échelle — en particulier quand de nombreuses machines doivent écrire simultanément dans la même base.

La leçon clé : SQLite n’est pas « petit » en capacité — il est petit en charge opérationnelle. C’est pourquoi il est si souvent choisi.

Ce que signifient vraiment « embarqué » et « sans serveur »

Deux mots qui peuvent sonner comme du marketing : embarqué et sans serveur. Pour SQLite, ils ont des significations précises et pratiques.

« Embarqué » = une bibliothèque, pas un service

SQLite n’est pas quelque chose que vous « lancez » en arrière‑plan comme PostgreSQL ou MySQL. C’est une bibliothèque logicielle que votre application lie et utilise directement.

Quand votre appli a besoin de lire ou écrire des données, elle appelle des fonctions SQLite dans le même processus. Il n’y a pas de démon de base de données séparé à démarrer, patcher ou redémarrer. L’application et le moteur de base vivent ensemble.

« Sans serveur » (à la manière de SQLite) = pas de processus serveur séparé

Le « sans serveur » de SQLite ne veut pas dire la même chose que les produits « serverless » des fournisseurs cloud.

• Les produits serverless cloud ont toujours des serveurs — vous ne les gérez juste pas. Vous vous connectez sur le réseau, payez pour capacité/usage, et les opérations s’exécutent sur une infra que vous ne contrôlez pas.
• SQLite serverless signifie qu’il n’y a simplement aucun serveur de base de données. La base est typiquement un fichier local, et votre appli lit/écrit ce fichier directement.

Comment les applis parlent à SQLite

Avec des bases client-serveur, votre code envoie du SQL via TCP à un autre processus. Avec SQLite, votre code exécute du SQL via des appels de bibliothèque (souvent via un binding langage), et SQLite lit/écrit le fichier de base sur disque.

Le résultat : pas de saut réseau, pas de pool de connexions à tuner, et moins de modes de défaillance (comme « impossible de joindre l’hôte DB »).

Ce que cela change pour l’exploitation

Pour beaucoup de produits, « embarqué + sans serveur » se traduit par moins d’éléments à gérer :

• Pas d’étape d’installation de base sur les machines développeurs
• Déploiements plus simples (surtout pour desktop, mobile et edge)
• Tests locaux plus faciles et environnements plus reproductibles

Cette simplicité explique largement la présence généralisée de SQLite — même quand des équipes pourraient choisir quelque chose de plus lourd.

L’avantage zéro‑configuration : livrer un fichier, pas un service

Le bénéfice le plus sous‑estimé de SQLite est aussi le plus simple : votre base de données est un fichier qui voyage avec votre appli. Pas de serveur à provisionner, pas de ports à ouvrir, pas de comptes utilisateurs à créer, et pas de checklist « la DB tourne‑t‑elle ? » avant de démarrer.

Déploiement et mises à jour simplifiés

Avec une base client-serveur, livrer une appli implique souvent de livrer de l’infra : instance DB, migrations, monitoring, credentials, et plan d’échelle. Avec SQLite, vous empaquetez typiquement un fichier .db initial (ou le créez au premier lancement) et l’application lit/écrit dedans.

Les mises à jour peuvent être plus simples : besoin d’une nouvelle table ou d’un index ? Vous livrez une mise à jour de l’application qui exécute les migrations contre le fichier local. Pour beaucoup de produits, cela transforme un déploiement multi‑étapes en une seule release.

Idéal pour desktop, mobile et edge

Le modèle « livrer un fichier » brille lorsque l’environnement est contraint ou distribué :

• Apps desktop : installer une fois, fonctionner hors ligne, stocker les données localement avec peu de formalités.
• Apps mobiles : un pattern éprouvé pour le stockage on‑device quand le réseau est intermittent.
• Appareils edge / kiosques / systèmes embarqués : moins d’éléments mobiles = moins de points de défaillance, utile quand l’administration distante est difficile.

Sauvegardes basées sur le fichier — mais prévoyez quand même

Copier un fichier de base semble trivial, et ça peut l’être — si vous le faites correctement. On ne peut pas toujours copier en toute sécurité un fichier de base actif avec une copie de fichier naïve pendant que l’appli écrit dedans. Utilisez les mécanismes de sauvegarde de SQLite (ou assurez‑vous d’un snapshot cohérent) et stockez les sauvegardes en lieu durable.

Moins de travail DBA dédié

Sans serveur à tuner et à surveiller, beaucoup d’équipes évitent une partie importante de la charge opérationnelle : patcher un service DB, gérer des pools de connexions, faire tourner les credentials, maintenir des réplicas. Il faut quand même un bon design de schéma et des migrations — mais l’empreinte opérationnelle est plus petite.

Fiabilité d’abord : transactions et intégrité des données

La popularité de SQLite ne tient pas qu’à la commodité. Une grande raison de la confiance qu’on lui accorde est qu’il privilégie la correction plutôt que les fonctionnalités tape‑à‑l’œil. Pour beaucoup d’apps, la fonctionnalité la plus importante est simple : ne pas perdre ni corrompre les données.

ACID, expliqué simplement

SQLite prend en charge les transactions ACID, ce qui veut dire que « vos données restent cohérentes même quand tout va mal ».

• Atomique : un changement est tout ou rien. Si une opération comprend 5 mises à jour et que l’appli plante après 3, SQLite ne vous laisse pas dans un état à moitié fait.
• Consistent : les règles que vous attendez restent vraies. Si votre app attend des soldes non négatifs, les transactions aident à maintenir l’ordre.
• Isolé : plusieurs opérations ne se marchent pas mutuellement sur les pieds. Une action ne lira pas les modifications à moitié écrites par une autre.
• Durable : une fois que SQLite dit qu’une transaction est commitée, elle doit toujours être là après un crash ou une coupure de courant.

Modes de journalisation (haut niveau)

SQLite atteint la sécurité face aux crashs en utilisant un journal — un filet de sécurité qui enregistre ce qui va changer pour permettre une récupération propre.

Deux modes courants :

• Journal de rollback : l’approche classique. SQLite peut « annuler » le travail incomplet si une écriture est interrompue.
• WAL (Write-Ahead Logging) : améliore souvent la concurrence en séparant lectures et écritures, et peut rendre la récupération rapide car les modifications sont appendues puis consolidées.

Vous n’avez pas besoin de connaître les détails pour en profiter : l’essentiel est que SQLite est conçu pour récupérer de manière prévisible.

Pourquoi cela compte plus que des fonctionnalités exotiques

Beaucoup d’applications n’ont pas besoin de clustering ou de types de données exotiques. Elles ont besoin d’enregistrements exacts, de mises à jour sûres et de la certitude qu’un crash n’aura pas corrompu les données utilisateurs. L’accent mis par SQLite sur l’intégrité est une des grandes raisons de son usage dans des produits où « ennuyeux et correct » bat « impressionnant et complexe ».

Performance : rapide parce que proche de votre code

SQLite semble souvent « instantané » parce que votre appli parle à la base en processus. Pas de serveur séparé à joindre, pas de handshake TCP, pas de latence réseau — une requête est un simple appel de fonction qui lit un fichier local (souvent aidé par le cache de pages du système d’exploitation), donc le temps entre « exécuter du SQL » et « obtenir des lignes » peut être surprenamment faible.

Où SQLite brille

Pour beaucoup de produits, la charge est principalement en lectures avec un flux modéré d’écritures : chargement d’état, recherche, filtrage, tri et jointures sur des tables petites à moyennes. SQLite excelle dans ces cas. Il fait des recherches indexées efficaces, des scans de plage rapides et des agrégations rapides quand les données tiennent confortablement sur le stockage local.

Les charges d’écriture modérées conviennent aussi — préférences utilisateur, files de synchronisation en arrière-plan, réponses d’API en cache, journaux d’événements, ou un magasin local‑first qui fusionne les changements plus tard.

Le goulot principal : la concurrence d’écriture

Le compromis de SQLite concerne la concurrence sur les écritures. Il supporte plusieurs lecteurs, mais les écritures nécessitent une coordination pour garder la base cohérente. Sous de fortes écritures concurrentes (beaucoup de threads/processus essayant de mettre à jour en même temps), vous pouvez rencontrer de la contention et des retries ou des erreurs « database is busy » si vous ne concevez pas l’accès et ne réglez pas le comportement.

Les fondamentaux SQL comptent toujours

SQLite n’est pas « rapide par défaut » si les requêtes sont mal conçues. Index, clauses WHERE sélectives, éviter des scans table complète inutiles et garder les transactions bien limitées font une grande différence. Traitez‑le comme une vraie base de données — parce que ça en est une.

Portabilité et modèle fichier unique

La caractéristique la plus distinctive de SQLite est aussi la plus simple : toute votre base est un fichier unique (plus éventuellement des fichiers annexes comme un journal WAL). Ce fichier contient le schéma, les données, les index — tout ce dont l’app a besoin.

Une base que vous pouvez transporter

Parce que c’est « juste un fichier », la portabilité devient une fonctionnalité par défaut. Vous pouvez le copier, l’attacher à un rapport de bug, le partager avec un collègue (si approprié) ou le déplacer d’une machine à l’autre sans mettre en place de serveur, d’utilisateurs ou d’accès réseau.

SQLite tourne sur quasiment toutes les plateformes majeures : Windows, macOS, Linux, iOS, Android, et une longue liste d’environnements embarqués. Ce support cross‑platform s’accompagne d’une stabilité à long terme : SQLite est célèbre pour sa prudence sur la compatibilité ascendante, donc un fichier de base créé il y a des années s’ouvre généralement toujours avec les versions récentes.

Tests portables et environnements reproductibles

Le modèle fichier unique est aussi une force pour les tests. Besoin d’un dataset connu pour une suite de tests unitaires ? Checkez un petit fichier SQLite (ou générez‑le pendant les tests), et chaque développeur et job CI part du même point. Besoin de reproduire un bug client ? Demandez le fichier DB (avec gestion de la confidentialité) et vous pouvez rejouer le problème localement — pas de « ça n’arrive que sur leur serveur ».

Note pratique : traitez le fichier DB comme une donnée d’application

Cette portabilité a un revers : si le fichier est supprimé ou corrompu, vos données sont perdues. Traitez la base SQLite comme n’importe quel actif applicatif important :

• stockez‑la dans le répertoire de données adapté au système
• incluez‑la dans les sauvegardes si nécessaire
• protégez‑la par permissions et chiffrement si besoin
• évitez les dossiers temporaires sauf si les données sont réellement jetables

Écosystème et outillage qui facilitent l’adoption

SQLite est simple à adopter en partie parce que vous démarrez rarement de zéro. Il est intégré à de nombreuses plateformes, livré avec des runtimes de langage courants, et offre une compatibilité « ennuyeuse » exactement souhaitable pour une base embarquée.

Intégrations que vous utiliserez vraiment

La plupart des stacks ont déjà un chemin bien balisé vers SQLite :

• Langages : Python (sqlite3 dans la librairie standard), Go (mattn/go-sqlite3), Java (JDBC drivers), .NET (Microsoft.Data.Sqlite), PHP (PDO SQLite), Node.js (better-sqlite3, sqlite3).
• Frameworks/ORMs : Rails (Active Record), Django, Laravel, SQLAlchemy, Prisma, Sequelize, Entity Framework.
• Mobile et desktop : iOS et macOS (SQLite disponible système), Android (APIs SQLite), wrappers comme Room (Android), GRDB (Swift), et de nombreux plugins React Native/Flutter.

Cette largeur importe car elle permet à votre équipe d’utiliser des patterns familiers — migrations, générateurs de requêtes, gestion de connexions — sans inventer de plomberie sur mesure.

Outils : de « jeter un œil au fichier » à des workflows réels

L’écosystème SQLite est étonnamment abordable. Le CLI sqlite3 permet d’inspecter tables, lancer des requêtes, dumper des données ou importer du CSV. Pour l’exploration visuelle, des outils desktop ou web (ex. SQLiteStudio, DB Browser for SQLite) aident les non‑spécialistes à valider rapidement des données.

Côté livraison, les outils de migration mainstream supportent souvent SQLite : migrations Rails, Django, Flyway/Liquibase, Alembic, et Prisma Migrate rendent les changements de schéma reproductibles.

Le cercle vertueux de la popularité

Parce que SQLite est si largement déployé, les problèmes sont bien compris : les bibliothèques sont éprouvées, les cas limites documentés, et les exemples communautaires nombreux. Cette popularité génère plus de support, ce qui facilite encore l’adoption.

Quand vous choisissez une bibliothèque, préférez des drivers/ORM activement maintenus pour votre stack, et vérifiez le comportement de concurrence, le support des bindings et la gestion des migrations. Une intégration bien soutenue fait souvent la différence entre un déploiement smooth et un week‑end de surprises.

Où SQLite apparaît : cas d’usage concrets

SQLite se comprend mieux en regardant où il est utilisé : des endroits où un serveur complet ajouterait coût, complexité et risques.

Apps mobiles et tablettes

Beaucoup d’apps mobiles ont besoin d’un magasin local fiable pour sessions utilisateur, contenu mis en cache, notes ou files « à uploader plus tard ». SQLite convient car c’est un fichier unique avec transactions ACID, donc vos données survivent aux crashs, batteries faibles et connexions instables.

C’est particulièrement utile pour les apps offline‑first et local‑first : on écrit tout localement, puis on sync en arrière‑plan quand le réseau est disponible. L’avantage n’est pas seulement le mode hors‑ligne — c’est la rapidité de l’UI et un comportement prévisible parce que lectures et écritures restent sur l’appareil.

Apps desktop et installateurs

Les logiciels desktop ont souvent besoin d’une base sans demander de configuration à l’utilisateur. Livrer un fichier SQLite (ou le créer au premier démarrage) simplifie l’installation et rend les sauvegardes évidentes : copier un fichier.

Des apps comme outils de compta, gestionnaires média et systèmes CRM légers utilisent SQLite pour garder les données proches de l’app, ce qui augmente les performances et évite les problèmes « le serveur DB est‑il lancé ? ».

Navigateurs et outils clients

SQLite apparaît dans des outils développeur et applications nécessitant un stockage structuré pour l’historique, les index et les métadonnées. Il est populaire car stable, portable et sans processus séparé.

Appareils embarqués et appliances

Routeurs, kiosques, terminaux point‑de‑vente et gateways IoT stockent souvent config, logs et petits jeux de données localement. Le faible encombrement de SQLite et sa portabilité en font un choix pratique pour le déploiement et les mises à jour.

Flux de travail développeur : dev local, tests, prototypes

Les devs utilisent SQLite pour prototypes rapides, bases locales de développement et fixtures de tests. C’est zéro setup, facile à reset et déterministe — des bénéfices qui accélèrent l’itération et fiabilisent les runs CI.

C’est aussi un pattern courant avec Koder.ai : les équipes démarrent avec SQLite pour itérer localement (ou un déploiement single‑tenant), puis exportent le code généré et migrent vers PostgreSQL quand le produit nécessite une montée en charge multi‑writer. Ce workflow « start simple, migrate when necessary » accélère la livraison initiale sans vous enfermer.

Quand SQLite n’est pas adapté

SQLite est un excellent choix par défaut pour le stockage local, mais pas universel. L’important est de le juger sur votre charge et vos besoins opérationnels — pas sur le battage médiatique.

Beaucoup d’utilisateurs écrivent en même temps

SQLite gère bien plusieurs lecteurs, mais les écritures sont plus contraintes car le fichier doit rester cohérent. Si de nombreux utilisateurs/processus modifient des données en parallèle — surtout depuis des machines différentes — une base client‑serveur (PostgreSQL, MySQL) est souvent plus appropriée.

Un signe courant : « tout marche sur un laptop », mais en production vous voyez des timeouts, de la contention de verrous ou des files d’attente autour des écritures.

Charges d’écriture lourdes et écritures parallèles élevées

SQLite peut être très rapide, mais il est optimisé pour un autre profil : beaucoup de lectures et un taux modéré d’écritures. Si votre système fait des insert/update à haute fréquence (ingestion de métriques, flux d’événements, files de tâches, logs à gros volume) et attend beaucoup d’écrivains parallèles, une DB serveur évoluera généralement plus prévisiblement.

Ce n’est pas qu’une question de vitesse — c’est aussi la constance de la latence : un pic d’écritures peut bloquer d’autres écrivains et parfois des lecteurs, créant des latences de queue difficiles à expliquer.

Contrôle d’accès centralisé, audit et accès réseau

Si vous avez besoin d’une base centralisée partagée sur le réseau avec contrôle d’accès par rôle, traçabilité, sauvegardes centralisées et gouvernance, SQLite n’est probablement pas le bon outil. Placer un fichier SQLite sur un partage réseau provoque souvent des problèmes de fiabilité et de verrouillage.

Une base serveur est préférable quand vous avez besoin de :

• authentification/autorisation centralisée
• audit des modifications
• sauvegardes gérées, réplication et récupération PITR
• accès distant sécurisé pour plusieurs services et équipes

Une façon pratique de décider

Posez deux questions :

1. À quoi ressemble la concurrence en production (combien d’écrivains, à quel point c’est bursty) ?
2. Qui va l’exploiter (avez‑vous besoin de contrôles centralisés et d’accès partagé) ?

Si la réponse honnête est « beaucoup d’écrivains » et « gouvernance centralisée », une base client‑serveur n’est pas surdimensionnée — c’est souvent la voie la plus sûre.

SQLite vs bases client-serveur : comparaison pratique

SQLite et des bases comme PostgreSQL/MySQL peuvent toutes stocker des tables et exécuter du SQL, mais elles sont conçues pour des formes de problèmes différentes.

Architecture : en‑process vs service réseau

SQLite s’exécute dans votre processus. Votre code appelle SQLite, et SQLite lit/écrit directement un fichier local.

Une base client‑serveur s’exécute comme un service séparé. Votre appli se connecte sur le réseau (même si c’est localhost), envoie des requêtes, et le serveur gère stockage, concurrence, utilisateurs et travaux d’arrière‑plan.

Cette différence explique la plupart des compromis pratiques.

Compromis opérationnels : simplicité vs contrôle central

Avec SQLite, le déploiement peut se résumer à livrer un binaire et un fichier. Pas de ports, pas de credentials, pas de mises à jour serveur — souvent un gros avantage pour desktop, mobile, edge et produits local‑first.

Les bases client‑serveur excellent quand vous avez besoin de gestion centralisée : de nombreuses applis/utilisateurs touchant la même base, contrôle d’accès fin, sauvegardes en ligne, réplicas de lecture et observabilité mature.

Mise à l’échelle : comment chacun croît

SQLite s’échelle typiquement par :

• scale vertical : disque/CPU plus rapides, meilleures requêtes, cache
• sharding naturel : une base par utilisateur, appareil, tenant, projet (pattern courant)
• graduation : migrer les workloads partagés/multi‑writer vers une DB serveur quand la coordination devient le goulot

Les bases client‑serveur s’évoluent plus facilement pour les workloads partagés via machines plus grosses, réplication, partitionnement et pooling.

Checklist rapide de décision

Choisissez SQLite si vous voulez des données locales, une opération minimale et qu’une seule instance d’app possède majoritairement les écritures.

Choisissez une DB client‑serveur si vous avez besoin de nombreux écrivains concurrents, d’accès réseau par plusieurs services, de gouvernance centralisée ou de haute disponibilité intégrée.

Si vous hésitez, commencez par SQLite pour la vitesse de livraison, et conservez une voie de migration claire (schémas, migrations, export/import) vers PostgreSQL plus tard (/blog/migrating-from-sqlite).

Conseils pour utiliser SQLite en production

SQLite peut fonctionner en production — mais traitez‑le comme une vraie base, pas un « fichier temporaire qu’on peut copier ». Quelques bonnes pratiques évitent surprises et interruptions.

Concurrence : garder les transactions courtes

SQLite supporte plusieurs lecteurs et (en général) un seul écrivain à la fois. Ça suffit pour beaucoup d’apps si vous concevez en conséquence.

Gardez les transactions d’écriture courtes et ciblées : faites le travail dans l’application d’abord, puis ouvrez une transaction, écrivez et commitez rapidement. Évitez les transactions longues qui gardent des verrous pendant des appels réseau, saisies utilisateur ou boucles lentes. Si vous avez des jobs en arrière‑plan, mettez en file les écritures pour qu’elles ne s’accumulent pas et ne bloquent pas les requêtes interactives.

Envisagez le mode WAL pour un meilleur comportement lecture/écriture

Le Write‑Ahead Logging (WAL) modifie la façon dont SQLite enregistre les changements pour que les lecteurs puissent souvent continuer à lire pendant qu’un écrivain est actif. Pour beaucoup d’apps — en particulier celles avec beaucoup de lectures et des écritures occasionnelles — WAL réduit les frictions « database is locked » et améliore le throughput.

WAL n’est pas magique : vous avez toujours un écrivain, et il faut prévoir les fichiers WAL supplémentaires sur le disque. Mais c’est un choix courant et pratique en production.

Sauvegardes et migrations : planifiez‑les

Même si SQLite est un fichier unique, vous avez besoin d’une stratégie de sauvegarde. Ne comptez pas sur des copies de fichier prises au hasard ; coordonnez les sauvegardes pour capturer un état cohérent (surtout sous charge).

Gérez aussi les changements de schéma avec des migrations. Versionnez‑les, exécutez‑les automatiquement pendant le déploiement et testez les chemins de rollback/forward quand c’est possible.

Testez comme en production

Utilisez le même schéma, index et paramètres critiques (mode de journal, etc.) en staging et dans les tests automatiques. Beaucoup de « surprises SQLite » n’apparaissent qu’avec la croissance des volumes et de la concurrence — faites des tests de charge réalistes avant la mise en prod.

Conclusion : « embarqué » est souvent une fonctionnalité, pas une limite

SQLite est omniprésent parce qu’il fait stocker des données comme on utilise une bibliothèque, pas comme on gère une infrastructure. Vous obtenez un moteur SQL éprouvé, des transactions ACID et un outillage mature — sans provisionner un serveur, gérer des utilisateurs ou surveiller une connexion réseau.

Pourquoi SQLite continue d’être choisi

Au mieux, SQLite est l’option « ça marche tout de suite » :

• Zéro configuration : livrez un fichier unique avec votre app et commencez à lire/écrire immédiatement.
• Fiabilité : les transactions protègent vos données même en cas de crash ou de coupure d’alimentation.
• Vitesse : les données sont à côté de votre code, pas de tour réseau pour la plupart des requêtes.
• Portabilité : la base est un fichier que vous pouvez copier, sauvegarder, synchroniser ou bundler pour les tests.
• Écosystème : drivers, migrations, outils d’administration et patterns d’hébergement sont bien connus.

La limitation clef à retenir

SQLite n’est pas conçu pour une concurrence d’écriture élevée ni pour un accès multi‑utilisateur centralisé sur le réseau. Beaucoup de lecteurs peuvent interroger à la fois, mais les écritures concurrentes lourdes (ou de nombreux clients partageant un seul fichier) sont des cas où une base client‑serveur est généralement plus sûre.

Une étape simple suivante

Commencez par décrire votre charge — puis choisissez l’outil le plus simple qui convient. Si votre appli est surtout locale, mono‑utilisateur ou « local‑first », SQLite est souvent parfait.

Checklist rapide

• La base vivra‑t‑elle sur l’appareil / sur la même machine que l’appli ?
• Les écritures sont‑elles relativement faibles ou faciles à sérialiser ?
• Avez‑vous besoin d’opération hors‑ligne et d’un déploiement simple ?
• Pouvez‑vous sauvegarder / synchroniser un fichier unique en sécurité ?
• Avez‑vous besoin de nombreux écrivains concurrents ou d’une base centrale partagée pour beaucoup d’utilisateurs ?

Si vous avez répondu « oui » aux quatre premières et « non » à la dernière, SQLite est un excellent choix par défaut.