Utiliser SQLite en production avec Laravel

L’utilisation de SQLite en production avec Laravel peut s’avérer très pertinente lorsque les besoins sont modestes et que l’on privilégie la simplicité. SQLite se distingue par la gestion de la base de données en tant que fichier unique, ce qui facilite la sauvegarde et le partage, sans nécessiter l’installation et la supervision d’un serveur de base de données dédié. Cette configuration peut même offrir de meilleures performances que MySQL lorsqu’on évite les appels inter-processus ou les requêtes réseau superflues qui alourdissent les interactions avec une base traditionnelle  .

Pour améliorer la concurrence en lecture et en écriture, il est recommandé d’activer le mode WAL (Write-Ahead Log). Ce mode consigne les écritures dans un fichier séparé, ce qui évite que les lecteurs et les rédacteurs se bloquent mutuellement. En Laravel, il suffit d’ajouter dans la configuration SQLite les paramètres journal_mode = wal et busy_timeout = 10000 afin que les lectures n’interrompent plus les écritures, et vice versa  .

Pour pousser les optimisations plus loin, certains PRAGMA peuvent être définis, que ce soit dans les fichiers de migration ou au démarrage de l’application. Parmi ceux-ci on trouve : synchronous = NORMAL, mmap_size = 128 Mo, cache_size = 1 000 000 pages, foreign_keys = true, temp_store = memory, busy_timeout = 5000, ainsi que d’autres réglages avancés. Leur application permet d’améliorer la robustesse et la rapidité de la base SQLite  .

Une alternative pratique consiste à utiliser le package Laravel Optimize DB, pensé par un membre de l’équipe Laravel. Il applique automatiquement toute une série de PRAGMA optimisés pour SQLite (comme auto_vacuum = incremental, journal_mode = WAL, page_size = 32768, mmap_size = 2 Go, etc.), via des migrations et un service provider. Bien que prometteur, ce package est encore à considérer avec précaution car il est toujours en développement et il est conseillé de sauvegarder ses données avant de l’utiliser en production  .

Il est essentiel de garder à l’esprit les limitations inhérentes à SQLite en production. Dès que l’on anticipe une montée en charge avec de nombreux accès concurrents en écriture, SQLite montre ses limites : il verrouille l’ensemble de la base pendant les écritures et ne supporte pas une architecture répartie sur plusieurs serveurs, ce qui rend impossible une mise à l’échelle horizontale facile  . De plus, certaines plateformes, comme Laravel Cloud, déconseillent SQLite car le système de fichiers y est éphémère : à chaque redéploiement, les fichiers .sqlite peuvent être réinitialisés, entraînant une perte de données. Dans ces environnements, d’autres solutions comme Serverless Postgres sont recommandées pour bénéficier à la fois de la persistance et de l’économie  .

Exemple de configuration dans un fichier Laravel config/database.php pour activer WAL et le timeout :

// config/database.php
'sqlite' => [
    'driver' => 'sqlite',
    'url' => env('DATABASE_URL'),
    'database' => env('DB_DATABASE', database_path('database.sqlite')),
    'prefix' => '',
    'foreign_key_constraints' => env('DB_FOREIGN_KEYS', true),
    'journal_mode' => 'wal',
    'busy_timeout' => 10000,
],

Si tu optes pour le package d’optimisation, tu devras l’installer puis exécuter une migration et une commande artisan :

composer require nunomaduro/laravel-optimize-database
php artisan db:optimize
php artisan migrate

Ces commandes appliquent en une fois toutes les optimisations pertinentes pour ton projet SQLite en production  .

En conclusion, SQLite peut très bien convenir à des applications Laravel en production lorsqu’il s’agit de services peu sollicités ou d’outils internes. Il permet de réduire la complexité opérationnelle tout en offrant de bonnes performances, surtout si l’on active WAL et d’autres PRAGMA optimisés. Toutefois, au-delà d’un certain seuil de charge, ou dans un contexte nécessitant une montée en charge horizontale, des solutions plus robustes telles que MySQL ou PostgreSQL restent à privilégier. La configuration doit toujours être adaptée au contexte d’usage, car chaque projet a ses propres contraintes.

Sources :

• Samuel Štancl - Using SQLite in production with Laravel