Flat-File-CMS oder Datenbank-CMS: eine Entscheidungshilfe
Redaktionelle Inhalte gehören in Dateien, Daten, die Besucher oder Programme zur Laufzeit schreiben, in eine Datenbank. Dateien bringen Versionierung mit Git und gemeinsame Auslieferung mit dem Code, die Datenbank Transaktionen und Auswertungen über viele verknüpfte Einträge.
Die Frage stellt sich für jede Art von Daten auf einer Website einzeln. Seiten, Blogbeiträge und Glossareinträge verhalten sich anders als Kundenkonten oder Bestellungen: Die einen entstehen in der Redaktion und ändern sich selten, die anderen entstehen bei jedem Besuch. Dieser Beitrag klärt, welche Ablage zu welcher Art von Daten passt.
Speicherprinzip
So speichert ein Flat-File-CMS Inhalte
Ein Flat-File-CMS legt jeden Eintrag als Textdatei im Dateisystem ab. In Statamic 6 ist das eine Markdown-Datei mit einem YAML-Kopf für die Felder, abgelegt im Ordner content/collections/ und dort je Sammlung in einem Unterordner. Auch die Feldstruktur (Blueprints), Navigationen und globale Einstellungen sind Dateien. Kirby beschreibt sich ebenso als dateibasiertes CMS, das keine Datenbank braucht, Grav als Flat-File-CMS, dessen Inhalt „ein Ordner mit Dateien“ ist.
Damit eine Seite nicht bei jedem Aufruf hunderte Dateien lesen muss, baut Statamic einen Index, den Stache. Er fasst die Inhalte zusammen und legt sie im Cache der Laravel-Anwendung ab. Laut Dokumentation ist der Stache flüchtig: Er lässt sich jederzeit ohne Datenverlust neu aufbauen, weil die Dateien die Quelle bleiben.
Ein Datenbank-CMS speichert dieselben Inhalte in Tabellen. WordPress empfiehlt dafür MySQL ab Version 8.0 oder MariaDB ab Version 10.11, TYPO3 unterstützt laut get.typo3.org MySQL, MariaDB, PostgreSQL und SQLite. Ohne laufende Datenbank zeigen diese Systeme keine Seite an.
Diese Website arbeitet selbst so. Sie läuft auf Statamic 6, Seiten, Blogbeiträge und das Glossar liegen als Dateien im Repository. Auch die Nutzerkonten liegen laut Konfiguration als Dateien vor, der Eloquent-Treiber für Datenbanken ist nicht installiert. Warum wir uns so entschieden haben, steht im Beitrag Warum wir Statamic 6 gewählt haben.
Stärken
Was Dateien besser können
Liegen Inhalte als Dateien neben dem Code, gelten für sie dieselben Werkzeuge wie für den Code.
Versionierung. Liegen Inhalte in einem Git-Repository, ist jede Änderung ein Commit mit Datum, Autor und genauer Differenz. Ein versehentlich gelöschter Absatz lässt sich aus der Historie zurückholen, ohne eine ganze Datenbanksicherung einzuspielen. Bei der REVONEER Website, die wir seit 2016 betreuen und die inzwischen auf Statamic läuft, werden laut Projektseite laufend Texte geschärft, die Bildsprache nachjustiert und neue Module ergänzt. Jede dieser Änderungen steht als eigener Commit in der Historie und lässt sich einzeln nachvollziehen oder zurücknehmen.
Auslieferung. Inhalte, Blueprints und Templates wandern gemeinsam durch Staging und Freigabe. Ein neuer Seitentyp kommt mit seinen ersten Inhalten in einer Lieferung, und es gibt keinen Schritt, in dem Datenbankinhalte zwischen Umgebungen kopiert werden müssen. Wie so eine Strecke aussieht, beschreibt der Beitrag Staging-Umgebung.
Backups. Eine Sicherung ist eine Kopie der Dateien, ein Abgleich mit dem Repository zeigt sofort, ob etwas fehlt. Einen Datenbankabzug und seine Wiederherstellung braucht es für die Inhalte nicht.
Eine Lücke hat das Modell: Ändern Redakteure Inhalte im Control Panel auf dem Produktivserver, entstehen dort Dateien, die nicht im Repository stehen. Wird danach ein älterer Stand aus Git ausgeliefert, überschreibt er diese Änderungen.
Statamic Pro schließt die Lücke mit einer Git-Integration. Sie hält Änderungen aus dem Control Panel automatisch als Commit fest, auf Wunsch mit Push in das gemeinsame Repository, und trägt die angemeldete Person als Autor ein. Laut Dokumentation lassen sich die Commits sammeln und zeitversetzt über die Warteschlange ausführen, damit nicht jeder gespeicherte Tippfehler einen eigenen Commit erzeugt. Die Auslieferung holt diese Commits vor jedem Deployment ab, und Konflikte zeigen sich in Git statt als stillschweigend überschriebene Texte. Statamic Core hat diese Integration nicht. Dann braucht es eine feste Regel, wer wann committet, oder Redakteure arbeiten nur auf einer Staging-Umgebung, von der aus ausgeliefert wird.
Belastungsgrenzen
Wo Dateien an ihre Grenzen kommen
Die Schwächen zeigen sich bei drei Arten von Last.
Viele Einträge. Der Stache muss alle Dateien kennen. Nach einem Deployment oder einem geleerten Cache wird er neu aufgebaut, und das dauert umso länger, je mehr Dateien es gibt. Die Statamic-Dokumentation empfiehlt deshalb, den Index bei der Auslieferung mit php please stache:warm vorzubereiten, ihn bei großen Websites parallel aufzubauen und den Watcher in Produktion abzuschalten, weil er sonst bei jedem Aufruf die Änderungszeiten aller Dateien prüft.
Daten von Besuchern. Kundenkonten mit Selbstregistrierung, Kommentare, Bestellungen oder viele Formulareinsendungen entstehen zur Laufzeit, nicht in der Redaktion. Dateien kennen keine Transaktionen über mehrere Datensätze und keine Abfragesprache für Auswertungen. Hinzu kommt der Datenschutz: Personenbezogene Daten gehören nicht in ein Repository, dessen Historie jede Version für immer aufbewahrt. Statamic legt Formulareinsendungen unter storage/forms ab. Dieser Ordner gehört in die .gitignore.
Parallele Schreibzugriffe. Schreiben ein Import aus dem Warenwirtschaftssystem, eine Schnittstelle und die Redaktion gleichzeitig, ordnet eine Datenbank die Zugriffe. Bei Dateien muss die Anwendung das selbst regeln.
Mischformen
Dateien für Inhalte, Datenbank für Daten
Die Entscheidung muss nicht für alles gleich ausfallen. Statamic trennt die Speicherung nach sogenannten Repositories: Sammlungen, Einträge, Formulare, Assets, Navigationen, Taxonomien, Revisionen und weitere. Mit dem Paket statamic/eloquent-driver lässt sich jedes davon einzeln in eine Datenbank verlegen. Die Installation fragt, welche Teile umziehen sollen, die übrigen bleiben Dateien. Nutzerkonten haben eine eigene Einstellung in config/statamic/users.php. Für den Rückweg gibt es Befehle, die Inhalte wieder als Dateien exportieren.
Eine mögliche Aufteilung: Seiten, Blog und Glossar bleiben Dateien und laufen durch Git, Kundenkonten, Bestellungen und Einsendungen liegen in Tabellen. Weil Statamic auf Laravel aufsetzt, kann die Anwendung daneben eigene Tabellen für Fachdaten führen. Welche Datenbank dafür passt, klärt der Beitrag MySQL oder PostgreSQL.
Gegenüberstellung
Flat-File-CMS und Datenbank-CMS im Vergleich
Die Tabelle fasst die Unterschiede für redaktionelle Websites zusammen.
| Datenbank-CMS | Flat-File-CMS | |
|---|---|---|
| Speicherort | Tabellen in MySQL, MariaDB oder PostgreSQL | Markdown- und YAML-Dateien im Dateisystem |
| Beispiele | WordPress, TYPO3 | Statamic im Standard, Kirby, Grav |
| Versionierung | über Revisionen im CMS, Sicherung als Datenbankabzug | jede Änderung als Commit in Git |
| Auslieferung | Code per Deployment, Inhalte getrennt kopieren | Inhalte und Code gemeinsam |
| Backup | Datenbankabzug plus Dateien | Kopie der Dateien, Abgleich mit dem Repository |
| Daten von Besuchern | ausgelegt für Schreibzugriffe zur Laufzeit | nur in kleinen Mengen, besser in einer Datenbank |
| Auswertungen | Abfragen mit SQL über verknüpfte Tabellen | Abfragen über den Index im Cache |
| Betrieb | Datenbankserver nötig | kein Datenbankserver für Inhalte nötig |
Entscheidungsfragen
Prüffragen für Ihre Website
Beantworten Sie jede Frage mit Ja oder Nein, und zwar getrennt für jede Art von Daten auf Ihrer Website.
Schreiben Besucher Daten, die gespeichert bleiben sollen, etwa Konten, Kommentare, Bestellungen oder Bewertungen?
Schreiben Programme mehrmals täglich automatisch Inhalte, etwa Importe aus der Warenwirtschaft oder Schnittstellen?
Brauchen Sie Auswertungen über viele verknüpfte Einträge, etwa Berichte oder Filter über Kategorien, Preise und Verfügbarkeit zugleich?
Soll jede Änderung an Inhalten nachvollziehbar und einzeln zurückholbar sein?
Sollen neue Seitentypen samt Inhalten über Staging geprüft und gemeinsam ausgeliefert werden?
Soll der Betrieb der Inhalte ohne Datenbankserver auskommen?
Wächst eine einzelne Sammlung auf mehrere zehntausend Einträge?
So werten Sie aus:
Ein Ja bei Frage 1, 2 oder 3 bedeutet: Diese Daten gehören in eine Datenbank. Sie entstehen zur Laufzeit oder werden relational ausgewertet, und dafür bieten Dateien weder Transaktionen noch eine Abfragesprache. Das gilt für diese Daten, nicht automatisch für die ganze Website.
Ein Ja bei Frage 4, 5 oder 6 spricht für Dateien bei den redaktionellen Inhalten, weil genau diese Anforderungen aus Git und gemeinsamer Auslieferung folgen.
Ja in beiden Gruppen ergibt die Mischform: Inhalte als Dateien, Laufzeitdaten in der Datenbank.
Ein Ja bei Frage 7 verlangt eine Messung. Statamic nennt keinen Grenzwert. Messen Sie auf einer Staging-Kopie mit realistischen Daten, wie lange php please stache:warm braucht und wie schnell gefilterte Listen laden, und entscheiden Sie dann für diese Sammlung.
Fragen zur Ablage
Häufige Fragen
-
Nicht grundsätzlich. Statamic liest bei einer Anfrage nicht jede Datei, sondern den Index im Cache, und fertige Seiten lassen sich zusätzlich statisch zwischenspeichern. Spürbar wird die Dateiablage vor allem beim Neuaufbau des Index nach einer Auslieferung und, wenn der Watcher in Produktion eingeschaltet bleibt.
-
Eine feste Zahl nennen weder Statamic noch Kirby oder Grav. Diese Website führt Seiten, Blog und Glossar als Dateien. Bei sehr großen Sammlungen gibt eine Messung auf Staging die verlässliche Antwort.
-
Bei Statamic geht das mit dem Eloquent-Treiber, und zwar für jedes Repository einzeln, etwa nur für Einträge einer großen Sammlung. Die Templates fragen Inhalte weiter über dieselben Tags ab. Bei anderen Systemen klären Sie den Weg vor der Wahl, weil nicht jedes CMS einen Wechsel der Ablage vorsieht.
-
Die Inhalte brauchen keine Datenbank. Die Anwendung darunter kann trotzdem eine Datenbank nutzen, etwa Laravel für Warteschlangen oder eigene Fachdaten, und Kirby kann über eine eigene Klasse MySQL oder SQLite anbinden. Für die Planung zählt deshalb, welche Daten wo liegen.
Nachweise
Quellen und Stand
Stand: 26.08.2026. Angaben zu Statamic laut Dokumentation auf statamic.dev, zu Kirby, Grav und WordPress laut den Herstellerseiten, zu TYPO3 laut get.typo3.org. Angaben zur eigenen Website aus dem Repository, zu REVONEER laut Projektseite.
Artikel teilen