Caisse multi-postes : SQLite ou PostgreSQL, lequel choisir ?

C est une question qui revient systématiquement chez les commerçants belges qui voient leur activité grandir : "ma caisse actuelle tourne sur SQLite et c est bien, mais on ouvre une 2e caisse, est-ce qu il faut migrer en PostgreSQL ?". La réponse courte est "ça dépend, mais souvent oui". La réponse longue, c est cet article.

1. SQLite et PostgreSQL : c est quoi exactement ?

SQLite est un moteur de base de données embarqué : la base est un simple fichier (.db) sur le disque, le logiciel y accède directement, pas de service à lancer. Pas de réseau, pas de serveur, pas de mot de passe à gérer. Parfait pour une caisse unique.

PostgreSQL est un serveur de base de données : un processus dédié qui tourne en arrière-plan, écoute sur un port (5432 par défaut), gère plusieurs clients simultanés via le réseau. Authentification, droits utilisateurs, sauvegardes à chaud, réplication. C est l outil qu utilisent Twitter, Instagram, et la majorité des SaaS B2B.

Les deux sont gratuits, open-source, matures (SQLite depuis 2000, PostgreSQL depuis 1996). Mais ils ne répondent pas du tout aux mêmes besoins.

2. SQLite mono-poste : quand c est le bon choix

Configuration idéale pour SQLite :

• Une seule caisse physique
• Pas de besoin de consulter les données depuis un autre PC
• Volume modéré (< 200 000 ventes / an)
• Pas d application tierce qui doit lire la base en temps réel

C est la configuration la plus simple, la plus fiable, la plus rapide à installer. Pas de configuration réseau, pas de port à ouvrir, pas de gestion d utilisateurs. La base entière tient dans un fichier que vous pouvez sauvegarder en le copiant. Le coût d hébergement est nul.

Limite stricte : un seul process peut écrire dans la base à la fois. Si vous essayez d ouvrir la même base depuis 2 caisses via un partage réseau, vous allez corrompre votre base en quelques jours (verrous SQLite mal gérés en réseau). C est la première cause de perte de données catastrophique chez les commerçants.

3. PostgreSQL multi-postes : quand c est obligatoire

Dès que vous avez 2 PCs qui doivent écrire des ventes en simultané, PostgreSQL devient obligatoire. Cas typiques :

• HORECA : caisse principale au bar + caisse mobile pour les serveurs (tablettes)
• Commerce : caisse principale + caisse au dépôt / atelier
• Multi-établissements : centralisation des ventes sur un site maître
• Backend web : un site distant qui doit lire en temps réel le CA du jour

Avec PostgreSQL, chaque caisse se connecte au serveur via le LAN. Les ventes, stocks, clients sont synchronisés en temps réel (millisecondes). Si une caisse tombe en panne, les autres continuent. Si vous voulez ouvrir une 3e ou 4e caisse, vous branchez le PC et c est fait.

4. Architecture "Master + Slaves" en LAN

Le pattern classique pour un commerce belge avec 2 à 6 caisses :

• Un PC "Master" héberge PostgreSQL + la caisse principale (le PC le plus solide)
• N PCs "Slaves" lancent le logiciel de caisse en mode client, se connectent au Master
• Le LAN local (Ethernet ou Wi-Fi 5+) porte le trafic SQL
• Pas besoin d Internet pour que les caisses fonctionnent
• Sauvegarde quotidienne automatique sur le Master (clé USB, NAS, ou cloud)

Avec ce setup, la latence est de 5 à 20 ms entre une action sur le slave et l update visible chez les autres caisses. Imperceptible en pratique.

5. Performances : ordres de grandeur

Sur du matériel standard (PC Intel i3, 8 Go RAM, SSD) :

• SQLite local : ~10 000 inserts/seconde, lecture de 1 M de lignes en < 1 sec
• PostgreSQL LAN : ~3 000 inserts/seconde par connexion, mais 50+ connexions simultanées sans souci

Concrètement, pour un commerce belge typique :

• Boutique 200 ventes/jour, 1 caisse : SQLite suffit largement (utilise 0,1 % de sa capacité)
• Restaurant 80 couverts/service, 3 caisses + tablette serveur : PostgreSQL nécessaire, charge à 5 % de sa capacité
• Supermarché 2000 transactions/jour, 5 caisses : PostgreSQL confortable, charge à 15 %
• Chaîne 10 magasins centralisée : PostgreSQL dans le cloud (AWS RDS, Azure Postgres) + caches locaux

Aucune installation HORECA en Belgique ne va saturer PostgreSQL en pratique. Le facteur limitant, c est plutôt le réseau local (Wi-Fi instable, switch saturé).

6. Fiabilité : qui résiste mieux aux crashs ?

SQLite :

• Fichier corrompu = besoin de restaurer la sauvegarde
• Coupure électrique pendant écriture = possible perte des dernières secondes
• Pas de réplication native
• Récupération facile (fichier portable, outils gratuits)

PostgreSQL :

• WAL (Write-Ahead Log) garantit la cohérence transactionnelle
• Récupération automatique après crash (rejoue les transactions en cours)
• Réplication maître-esclave en standard (réplique chaude possible)
• Sauvegarde à chaud sans interrompre le service (pg_dump ou WAL streaming)
• Outils pro de monitoring (pg_stat, Prometheus exporters)

Pour un commerce qui ne peut pas se permettre de perdre 1 heure de ventes, PostgreSQL est nettement plus fiable. Mais SQLite, avec une sauvegarde toutes les 15 minutes, reste robuste pour 99 % des cas.

7. Coût total de possession (TCO)

SQLite :

• Licence : gratuit
• Hardware : 1 PC suffit (la caisse principale)
• Maintenance : aucune
• Sauvegarde : 1 ligne de script (cp database.db backup-YYYYMMDD.db)
• Total annuel : ~0 € en plus du PC

PostgreSQL :

• Licence : gratuit
• Hardware : 1 PC "Master" un peu plus costaud (i5, 16 Go RAM, SSD NVMe), ~600 € HTVA
• Hardware : N PCs "Slaves" classiques
• Maintenance : 1 à 2 heures / mois (mises à jour, monitoring, sauvegardes)
• Sauvegarde : automatisation cron ou outil tiers (pgBackRest gratuit, ~30 € HTVA mensuel pour hébergé)
• Total annuel : 200 à 500 € HTVA (hors PC)

Pour un commerce qui génère 250 k€ de CA, la différence est marginale. Pour une boulangerie de quartier qui fait 50 k€, SQLite reste plus rationnel.

8. Quand migrer de SQLite vers PostgreSQL ?

Les 4 signaux qui doivent déclencher la migration :

1. Ouverture d une 2e caisse physique (le plus évident)
2. Besoin de consulter le CA en temps réel depuis un autre PC (gérant, comptable)
3. Volume > 500 000 lignes dans la base (SQLite devient lent au-delà)
4. Intégration avec une application tierce (e-commerce, ERP, BI) qui doit lire en parallèle

Si vous cochez 1 ou plus de ces cases, planifiez la migration avant que le problème soit critique. Une migration en urgence un samedi de saison touristique = catastrophe garantie.

9. La migration SQLite → PostgreSQL en pratique

Étapes typiques (3 à 5 heures de travail, hors formation) :

1. Installer PostgreSQL sur le futur Master (Windows installer ou via paquet Linux)
2. Créer la base et l utilisateur applicatif avec les bons droits
3. Exporter SQLite : sqlite3 base.db .dump > export.sql
4. Adapter le SQL pour PostgreSQL (types légèrement différents : INTEGER PRIMARY KEY AUTOINCREMENT → BIGSERIAL PRIMARY KEY)
5. Importer : psql -U user -d base < export.sql
6. Tester : lancer la caisse en mode PostgreSQL, vérifier les ventes récentes
7. Mettre à jour la config sur tous les PCs slaves (string de connexion)
8. Garder la SQLite en backup pendant 3 mois au cas où

Un éditeur de logiciel sérieux fournit un assistant de migration qui automatise les étapes 3 à 6. Comptez 1 à 3 heures pour une boutique typique, 1 journée pour un restaurant.

10. Cas particulier : le "cloud full SaaS"

Une option émergente en 2026 : PostgreSQL hébergé dans le cloud (AWS RDS, Azure Postgres, Supabase) avec les caisses qui se connectent en HTTPS via API. Avantages :

• Pas de Master physique à gérer
• Sauvegardes automatiques par le fournisseur
• Accès depuis n importe où

Inconvénients :

• Dépendance Internet : si la connexion tombe, la caisse aussi (à moins de cache local)
• Latence : 30 à 80 ms par requête vs 5-20 ms en LAN
• Coût récurrent : 30 à 100 € HTVA / mois pour l hébergement Postgres

Pour 95 % des commerces belges, PostgreSQL en LAN local reste le meilleur compromis : zéro dépendance Internet, latence imperceptible, coût marginal. Le cloud full SaaS commence à avoir du sens pour les chaînes 5+ établissements ou les pure players e-commerce omnicanal.

---

Pour aller plus loin

AuraPOS supporte les deux modes : SQLite mono-poste pour démarrer, migration assistée vers PostgreSQL quand vous ouvrez une 2e caisse. Pas de changement de logiciel, pas de perte de données, pas de réformation des équipes. Téléchargement direct ici.

Pour comprendre l architecture multi-postes en détail, consultez la documentation backend web. Une question sur votre cas spécifique ? Contactez-nous.