Version : 1.0 — Mars 2026 Scope : Tout projet Gentle Designs nécessitant une base de données Objectif : Choisir le bon moteur de BDD selon le profil de requêtes, le volume de données, et le contexte de déploiement
Trois profils, trois moteurs
| Profil de requêtes | Moteur | Exemples |
|---|---|---|
| Single-user, CRUD simple, peu de données (<100K lignes) | SQLite | App de notes, config locale, site vitrine avec données |
| Single-user, analytique lourd, millions de lignes, requêtes ad hoc | PostgreSQL embarqué ou DuckDB | EVQuest (destination), H2N, PokerTracker, HM3, outils data desktop |
| Multi-user, web, concurrence d'écriture | PostgreSQL hébergé (Supabase, Neon, Railway) | SaaS, apps client Gentle Designs, dashboards |
Critères détaillés
Volume de données
- <100K lignes avec requêtes simples → SQLite suffit largement
- Millions de lignes avec agrégations complexes → PostgreSQL. Son optimiseur de requêtes parallélise, choisit entre différents types de scans, utilise des index partiels ou composites de manière bien plus intelligente que SQLite.
Nature des requêtes
- CRUD prévisible (le développeur écrit toutes les requêtes) → SQLite acceptable
- Requêtes ad hoc construites par l'utilisateur (filtres, agrégations custom) → PostgreSQL. On ne peut pas anticiper chaque combinaison, et le planificateur de PostgreSQL encaisse ces requêtes imprévisibles bien mieux.
- Analytique pure (colonnes, agrégations massives, peu d'écritures) → DuckDB — moteur analytique embarqué comme SQLite (fichier unique, zéro serveur) mais optimisé pour les agrégations sur des millions de lignes.
Contexte de déploiement
- App desktop distribuée via installeur → SQLite ou PostgreSQL embarqué (qui démarre/s'arrête avec l'app, invisible pour l'utilisateur — pattern H2N/Pokstats)
- App web → PostgreSQL hébergé (Supabase, Neon)
- Prototype/POC → SQLite pour la vitesse de setup, puis migrer
Concurrence
- Un seul utilisateur → SQLite ou PostgreSQL embarqué
- Plusieurs utilisateurs simultanés en écriture → PostgreSQL hébergé obligatoire (SQLite = un seul writer à la fois)
Pattern recommandé : couche d'abstraction dès le départ
Utiliser un ORM ou une couche d'abstraction (SQLAlchemy en Python, Prisma/Drizzle en TypeScript) dès le premier jour. La migration de moteur se réduit alors à changer la chaîne de connexion + ajouter des index spécialisés. 95% du code reste identique.
# SQLAlchemy — changer de moteur = changer une ligne
# SQLite
engine = create_engine("sqlite:///app.db")
# PostgreSQL embarqué
engine = create_engine("postgresql://localhost:5432/app")Leçon EVQuest
SQLite était le bon choix pour le MVP — avancer vite, zéro dépendance. Mais la destination finale est PostgreSQL embarqué pour deux raisons :
- Volume de plusieurs millions de mains avec agrégations croisées (position × stack × type de tournoi × période)
- Stats custom créées par l'utilisateur (requêtes ad hoc non anticipables)
Tous les concurrents sérieux (Hand2Note, PokerTracker 4, HM3) utilisent PostgreSQL — ce n'est pas un hasard.
Rappel vibe coding
Dans un workflow où Claude Code produit 99,9% du code, la complexité d'implémentation d'une migration de BDD n'est plus un facteur de décision. Seule la justesse de l'architecture compte. Si PostgreSQL est la bonne cible, y aller directement — ne pas "commencer petit" par paresse technique quand le vrai coût est nul.
Dernière mise à jour : mars 2026