SQLite
Moteur de base de données relationnelle open-source intégré directement dans l'application — sans serveur, sans configuration réseau, sans processus externe. Stockée dans un seul fichier, SQLite supporte le SQL standard, les transactions ACID et est déployée dans des milliards d'appareils à travers le monde.
Demander un audit gratuit →Pourquoi utiliser SQLite dans vos projets ?
SQLite convient à une large gamme de projets qui n'ont pas besoin de la complexité d'un SGBD client-serveur. Voici pourquoi elle s'impose là où la simplicité et la rapidité de mise en route comptent.
Zéro configuration serveur
Pas de processus à démarrer, pas de port à ouvrir, pas de credentials à gérer. La base de données est un simple fichier sur le disque. Le temps de mise en route passe de plusieurs heures à quelques secondes.
Un seul fichier portable
Toute la base tient dans un fichier `.db` facile à sauvegarder, copier, transférer ou versionner avec Git pour les petites bases de référence. Les migrations et les sauvegardes se résument à une copie de fichier.
Performances en lecture optimales
Pour les applications à lecture intensive avec une concurrence limitée, SQLite est souvent plus rapide que PostgreSQL — pas de latence réseau, pas de sérialisation/désérialisation des paquets. Les requêtes locales sont immédiates.
Intégration Python native
Le module `sqlite3` est inclus dans la bibliothèque standard Python — aucune dépendance à installer. SQLite est également compatible SQLAlchemy sans driver additionnel, ce qui permet de basculer vers PostgreSQL en changeant une URL.
Pour quel type de projet utiliser SQLite ?
Des cas d'usage concrets, tels qu'on les rencontre chez les PME et ETI françaises.
Environnement de développement local
SQLite est le choix par défaut pour le développement local d'une application FastAPI, Django ou Flask. Aucun serveur PostgreSQL à installer, aucune variable d'environnement à configurer : on démarre immédiatement. En production, une simple variable `DATABASE_URL` bascule vers PostgreSQL sans toucher au code applicatif si SQLAlchemy est utilisé.
Outil interne ou application desktop mono-utilisateur
Une application utilisée par une seule personne à la fois — tableau de bord local, outil de gestion de fichiers, gestionnaire de contacts — n'a pas besoin d'un serveur de base de données. SQLite gère parfaitement ces usages avec des performances excellentes et une empreinte mémoire inférieure à 1 Mo.
Stockage de données pour agents IA et pipelines LLM
Les agents LangGraph et LangChain utilisent SQLite pour persister leur mémoire conversationnelle, leurs traces d'exécution ou leurs checkpoints d'état. La légèreté de SQLite en fait le choix naturel pour les pipelines d'automatisation qui tournent sur un serveur sans infrastructure dédiée.
Prototype et MVP avant migration vers PostgreSQL
SQLite permet de valider rapidement un modèle de données et une logique métier sans investir dans une infrastructure de base de données. Alembic gère les migrations de la même façon qu'avec PostgreSQL. Quand le projet grossit, la migration vers PostgreSQL se fait en quelques heures.
Application Streamlit ou reporting embarqué
Les dashboards Streamlit qui lisent des données locales — fichiers CSV transformés, exports ERP, résultats de scraping — bénéficient d'un cache SQLite pour éviter de recharger les données à chaque interaction. SQLite sert aussi de base pour les applications de reporting déployées en interne sur un poste ou un serveur sans DBA.
Questions fréquentes sur SQLite
Ce que nos clients demandent avant de choisir SQLite pour leur projet.
PostgreSQL est conçu pour les applications multi-utilisateurs, les forts volumes et les accès concurrents élevés — c'est le choix pour tout SaaS ou application web en production. SQLite est optimisée pour un accès local, séquentiel ou à faible concurrence. Une règle simple : si votre application a plusieurs utilisateurs simultanés ou si les données sont partagées entre plusieurs serveurs, choisissez PostgreSQL. Pour tout le reste — développement, prototypage, outils internes, pipelines — SQLite est souvent suffisant.
SQLite supporte la lecture concurrente mais limite les écritures simultanées : une seule écriture à la fois, les autres attendent (WAL mode améliore cela en permettant les lectures pendant une écriture). Pour une application web avec plusieurs dizaines de requêtes par seconde en écriture, SQLite atteint ses limites. En dessous de ce seuil — applications internes, sites à trafic modéré — elle est parfaitement capable.
SQLite stocke les données en clair par défaut. Pour des données sensibles, des extensions comme SQLCipher ajoutent le chiffrement AES-256 du fichier de base de données. Les accès sont contrôlés par les permissions système du fichier — pas de gestion utilisateur native comme PostgreSQL. Pour des données très sensibles en production partagée, PostgreSQL avec ses rôles et ses ACL est plus adapté.
Oui, si l'application utilise un ORM comme SQLAlchemy. Il suffit de changer la variable `DATABASE_URL` (`sqlite:///...` → `postgresql://...`) et de relancer les migrations Alembic sur la nouvelle base. Le code applicatif ne change pas. Le principal point d'attention : quelques types SQL ou comportements diffèrent entre SQLite et PostgreSQL (notamment pour les colonnes JSON, les contraintes et le mode strict).
Oui, complètement. SQLAlchemy supporte SQLite nativement via le dialecte `sqlite://`, sans driver externe à installer. Alembic génère et applique les migrations de la même façon qu'avec PostgreSQL. La seule limitation connue : Alembic ne peut pas modifier les colonnes existantes sur SQLite via `ALTER TABLE` (SQLite ne le supporte pas) — il faut recréer la table, ce qu'Alembic gère automatiquement avec `batch_alter_table`.
Un projet avec SQLite ?
30 minutes d'audit pour cadrer votre besoin et vous proposer une architecture adaptée.
Demander un audit gratuit →