Statamic : flat file ou base de données — quel choix ?
Par défaut, Statamic stocke le contenu en fichiers (Markdown, YAML) : idéal pour Git, les déploiements simples et les sites vitrine. Mais on peut aussi basculer tout ou partie du CMS en base de données via le driver Eloquent — utile pour un SaaS, du multisite ou des flux entre applications.
Ce volet compare les deux approches et propose un cas concret (site marketing en flat file + produit client en BDD).
Statamic : flat file ou base de données ?
Après les blueprints et l’affichage Antlers / Blade, on regarde où vit le contenu : fichiers sur le disque ou tables Laravel.
Statamic propose deux modes dès l’installation ; on peut aussi mixer (certaines parties en fichiers, d’autres en base). Référence principale : Storing Content in a Database.
Flat file (mode par défaut)
En flat file :
- les entrées de collection sont des fichiers Markdown (
.md) souscontent/collections/; - les blueprints, collections, fieldsets, etc. sont surtout du YAML sous
resources/blueprints/,content/collections/*.yaml, etc.
Avantages
- Versionning Git : pas besoin d’exporter/importer une base entre local, préprod et prod — on commit et on déploie les fichiers.
- Pas de base obligatoire pour faire tourner Statamic (pratique pour un site vitrine ou un blog).
- Debug client : si un client modifie du contenu en prod, vous récupérez les commits, vous reproduisez en local, vous corrigez template ou structure, puis vous redéployez.
C’est l’option recommandée par Statamic dans la majorité des cas — et elle suffit largement pour un site de formation, un portfolio ou un marketing classique.
Mode base de données (Eloquent)
Statamic s’appuie sur Laravel et Eloquent : on peut stocker collections, entrées, blueprints, taxonomies, formulaires, etc. en BDD.
Les entrées sont souvent sérialisées dans un champ type JSON (data) avec l’ensemble des valeurs de champs — le CP et les APIs fonctionnent comme en flat file.
Quand c’est pertinent
- SaaS multi-clients : chaque client alimente des pages/collections ; vous devez interroger la même base depuis plusieurs apps ou workers.
- Multisite / multilingue avancé avec beaucoup de contenu dynamique.
- Workflow où la BDD est déjà le centre (sync, reporting, jobs Laravel).
Cas concret : deux applications dans un même produit
Exemple (projet type « sites pour églises » / générateur de sites) :
| Application | Rôle | Stockage Statamic |
|---|---|---|
| Site marketing | Vitrine, inscription, paiement (Stripe…) | Flat file — contenu simple, déploiement Git |
| App produit | CMS par client, pages générées, multisite | BDD — entrées et collections alimentées par les clients |
Sur le repo marketing : Statamic « classique », pas besoin de migrer le contenu en base.
Sur le repo produit : entrées et collections (et éventuellement taxonomies, navigations…) en base, car ce sont les clients qui créent le contenu. Les blueprints et fieldsets restent souvent en fichiers : ce sont vous qui définissez les modules, vous les versionnez en Git, pas besoin qu’ils vivent en BDD.
Passer (ou revenir) en base de données
-
Configurer la base dans
.env(SQLite par défaut sur un projet Laravel récent, ou MySQL/PostgreSQL). -
Lancer la commande d’installation du driver :
php please install:eloquent-driver
L’addon Eloquent Driver s’installe, la config est publiée, puis le CLI vous propose quels dépôts migrer (entries, collections, blueprints, forms, globals, etc.).
- Statamic peut créer les migrations et importer les YAML/Markdown existants vers la base.
Revenir au flat file
Des commandes d’export existent, par exemple :
php please eloquent:export-entries
php please eloquent:export-collections
php please eloquent:export-blueprints
(et d’autres cibles : globals, navs, taxonomies, forms… — liste complète dans la doc.)
Vous gardez la main : BDD → fichiers, ou l’inverse.
Documentation : retrouver les bons articles
Dans la doc Statamic, recherchez « eloquent » : vous tombez notamment sur :
- Storing Content in a Database — commande
install:eloquent-driver, exports, logique générale ; - un guide du type Building your own entry repository — si vous voulez brancher un repository d’entrées personnalisé (cas avancé, intégration métier sur mesure).
La doc est complète mais dispersée : ces deux pistes suffisent souvent pour démarrer le mode BDD.
Vidéo : flat file vs BDD en pratique
Conclusion
- Flat file : simple, Git-friendly, idéal pour la plupart des sites et pour votre blog / formation.
- Base de données : pertinent pour un produit multi-tenant, du contenu très dynamique ou des échanges avec d’autres services Laravel.
- Mix possible : blueprints/fieldsets en fichiers (vous), entrées/collections en BDD (clients).
Choisissez selon le workflow de déploiement et qui écrit le contenu, pas selon une mode « plus pro » : les deux sont officiels et supportés.
