ostrelle
Menü

OSTRELLE · WEBSITES MIT KLAREM BLICK

CMS ohne Datenbank: Flatfile, SQLite oder Datenbankserver?

CMS ohne Datenbank: Flatfile, SQLite und Datenbankserver im Vergleich, mit Vor- und Nachteilen, Backup-Folgen und Entscheidungsbaum für dein Projekt.

← Zum Wissensbereich

Autor: Ostrelle-Projektredaktion · Stand: 30. Oktober 2026. Herausgeber ist das Ostrelle-Projekt (Burak Basci), das ein eigenes CMS entwickelt. Dieser quellenbasierte Ratgeber ist keine unabhängige Produktempfehlung und kein eigener Vergleichstest.

Wer ein einfaches CMS ohne Datenbank sucht, meint meist: wenig Betriebsaufwand und leichte Sicherungen. Doch „ohne Datenbank“ umfasst mindestens drei verschiedene Bauarten, und jede hat andere Grenzen. Dieser Ratgeber erklärt die Unterschiede, nennt Beispiele aus den Herstellerdokumentationen und führt dich mit einem Entscheidungsbaum zur passenden Bauart, auch wenn du statt eines CMS gleich eine Website ohne CMS erstellen willst.

1. Was „ohne Datenbank“ heißt

Wichtig für die Einordnung: Ein „CMS ohne Datenbank“ beschreibt nur, wo Inhalte liegen, nicht, ob ein Redaktionssystem im Browser vorhanden ist. Kläre deshalb beide Fragen getrennt: Wo liegen die Daten? Wie bearbeiten Menschen sie?

  • Flatfile: Inhalte liegen als Dateien und Ordner vor, meist Text oder Markdown. Eine Seite ist eine Datei, ein Ordner ist eine Seitengruppe.
  • Eingebettete Datenbank, zum Beispiel SQLite: Es gibt eine Datenbank, aber keinen Server. Sie ist eine Datei, die die Anwendung direkt öffnet.
  • Datenbankserver wie MySQL, MariaDB oder PostgreSQL: ein eigener Dienst, den die Anwendung über das Netzwerk oder lokal anspricht.
  • Statisch erzeugte Website: Ein Generator baut vorab fertige HTML-Dateien. Beim Besuch läuft keine Anwendung.

2. Flatfile-CMS: Dateien statt Datenbank

Grav ist ein Beispiel. Die Dokumentation beschreibt es als dateibasierte Plattform mit Markdown für die Inhalte (Überblick bei Grav) und stellt klar: Es wird keine Datenbank benötigt, weil Inhalte als Textdateien gespeichert sind. Quelle: Grav-Anforderungen. Grav braucht aber PHP; die dort genannte Mindestversion 7.3.6 ist älter als PHP 7.4, das WordPress.org bereits als abgelaufen bezeichnet. Prüfe die aktuell unterstützte Version selbst.

Kirby arbeitet ähnlich. Laut Hersteller speichert es Inhalte in einfachen Textdateien, Ordner sind Seiten. Quelle: Kirby. Kirby ist auf PHP angewiesen und verlangt für veröffentlichte Websites eine Lizenz; für nicht öffentlich erreichbare Entwicklungsinstallationen gibt es eine kostenlose Lizenz. Quelle: Kirby-Schnellstart.

Vorteile (eigene Einordnung): Der Inhalt ist lesbar und lässt sich mit Versionsverwaltung sichern; ein Backup besteht im Kern aus einer Dateikopie. Es gibt keinen Datenbankdienst, der gepflegt werden muss. Nachteile: Bei vielen Seiten, vielen gleichzeitigen Schreibzugriffen oder komplexen Abfragen (Filter, Suche über Felder, Nutzerkonten, Bestellungen) stoßen dateibasierte Systeme schneller an Grenzen als Datenbanken. Schreibzugriffe aus Formularen musst du zusätzlich absichern.

3. Statische Generatoren: gar kein Laufzeitsystem

Hugo beschreibt sich als statischen Website-Generator in Go, optimiert für Geschwindigkeit; er rendert eine komplette Website laut Anbieter in Sekunden oder weniger. Quelle: Hugo-Einführung. Inhalte schreibst du standardmäßig in Markdown, wie die Hugo-Dokumentation zu Inhaltsformaten zeigt.

Das passt, wenn du ein „CMS ohne PHP“ suchst: Auf dem Webserver liegen nur fertige Dateien (eigene Einordnung). Dafür gibt es keine Bearbeitung im Browser; Änderungen laufen über Dateien und einen erneuten Build. Formulare, Suche oder Kommentare brauchst du dann als externe Dienste oder zusätzliche Komponenten. Wenn du eine Website ohne CMS erstellen willst, ist ein Generator oder handgeschriebenes HTML der nächste Schritt.

4. SQLite: Datenbank ohne Server

Das SQLite-Projekt hält Websites mit weniger als 100.000 Zugriffen pro Tag für gut geeignet; die Zahl sei eine vorsichtige Schätzung, keine harte Obergrenze. Als Gegenbeispiel nennt es eine Website mit etwa 400.000 bis 500.000 Anfragen täglich. Quelle: SQLite – When To Use.

Die Grenzen nennt dieselbe Seite deutlich: SQLite erlaubt beliebig viele gleichzeitige Leser, aber nur einen Schreiber zugleich. Bei vielen gleichzeitigen Schreibzugriffen, bei sehr großen Datenmengen oder wenn mehrere Rechner über ein Netzwerk direkt auf dieselbe Datei zugreifen, empfiehlt sie eine Client/Server-Datenbank. Netzwerkdateisysteme gelten wegen Latenz und teils fehlerhafter Dateisperren als heikel.

Backups: Eine laufende SQLite-Datenbank solltest du nicht blind per Dateikopie sichern. Das Projekt beschreibt die Online-Backup-API sowie VACUUM INTO als Wege zu einem konsistenten Abbild. Quelle: SQLite Backup.

5. Datenbankserver: mehr Betrieb, mehr Spielraum

WordPress empfiehlt derzeit MariaDB 10.11 oder höher beziehungsweise MySQL 8.0 oder höher. Quelle: WordPress-Anforderungen. Auch Ghost nennt MySQL 8 für den Selbstbetrieb. Quelle: Ghost-Hosting.

Der Gewinn: viele gleichzeitige Schreibzugriffe, getrennter Datenbankdienst, ausgereifte Abfragen. Die Kosten: Ein Dienst, den du aktuell halten, sichern und überwachen musst. PostgreSQL nennt drei grundverschiedene Sicherungswege: SQL-Dump, Dateisystem-Sicherung und kontinuierliche Archivierung, jeweils mit eigenen Stärken und Schwächen. Quelle: PostgreSQL-Dokumentation.

6. Entscheidungsbaum: welche Bauart passt?

Unsere Faustregel: Wähle die einfachste Bauart, die deine Schreibzugriffe und Teamgröße trägt, und halte den Wechselweg offen. Exportiere Inhalte regelmäßig in ein offenes Format.

  • Seitenanzahl: Bis zu einigen Dutzend Seiten reichen Flatfile oder ein Generator. Bei Hunderten oder Tausenden Inhalten mit Filtern und Suche ist eine Datenbank im Vorteil.
  • Schreibzugriffe: Ändern nur Redakteure selten Inhalte? Dann genügen Dateien. Kommen Formulare, Kommentare, Nutzerkonten, Buchungen oder Bestellungen dazu, brauchst du eine Datenbank, bei vielen gleichzeitigen Schreibern einen Datenbankserver.
  • Teamgröße: Eine Person, die Dateien versioniert, kommt mit Flatfile oder Generator aus. Mehrere Redakteure mit Rollen und Browser-Bearbeitung brauchen ein Redaktionssystem mit Benutzerverwaltung.
  • Backups: Bei Dateien kopierst du Ordner. Bei SQLite brauchst du ein konsistentes Verfahren, bei einem Datenbankserver ein abgestimmtes Datenbank-Backup plus Dateien. Plane den Wiederherstellungstest ein.
  • Betrieb: Wenn du keinen Dienst pflegen willst, wähle Generator oder Flatfile. Wenn du einen Hoster mit Datenbankdienst nutzt, ist ein klassisches CMS häufig bequemer.

7. Wo Ostrelle steht: nicht „ohne Datenbank“

Offenlegung: Der Herausgeber entwickelt Ostrelle. Ostrelle ist ausdrücklich kein CMS ohne Datenbank. Der integrierte Quellstand unterstützt SQLite und natives PostgreSQL. Transfer und verschlüsselter PG-Restore haben eigene lokal geprüfte Betreiberpfade; eine Kundenfreigabe entsteht daraus nicht automatisch. Das hat Folgen für Sicherungen: Ein Verfahren für SQLite ist nicht automatisch ein PostgreSQL-Backup, wie die Seite Backups und Updates festhält.

Ostrelle bietet im Pilot unter anderem Revisionen, persönliche Autoentwürfe und kooperative Sperren. Welche Funktionen vorhanden sind und welche offen bleiben, steht im Entwicklungsstand. Wenn du heute ein einfaches Flatfile-CMS oder einen Generator brauchst, nimm ein Werkzeug aus Abschnitt 2 oder 3.

Häufige Fragen

Gibt es ein CMS ohne Datenbank?

Ja. Grav und Kirby speichern Inhalte laut ihrer Dokumentation in Dateien; Grav gibt ausdrücklich an, dass keine Datenbank nötig ist. Beide setzen aber PHP voraus.

Gibt es ein CMS ohne PHP?

Statische Generatoren wie Hugo erzeugen vorab HTML-Dateien, auf dem Webserver läuft dann nur die Auslieferung. Dafür fehlt die Bearbeitung im Browser.

Reicht SQLite für eine Website?

Laut SQLite-Projekt funktionieren Websites mit weniger als 100.000 Zugriffen pro Tag in der Regel gut. Bei vielen gleichzeitigen Schreibzugriffen empfiehlt das Projekt eine Client/Server-Datenbank.

Wie sichere ich ein CMS mit SQLite?

Nutze ein konsistentes Verfahren wie die Online-Backup-API oder VACUUM INTO, statt eine laufende Datenbankdatei blind zu kopieren. Teste außerdem die Wiederherstellung.

Primärquellen und Quellenstand

Die folgenden Quellen wurden am 30. Oktober 2026 für diesen Ratgeber abgerufen. Einordnung und Empfehlungen sind unsere Auswertung; sie ersetzen keine Rechtsberatung und keinen Test deines konkreten Vorhabens.

Weiterlesen

Selbst betreiben statt gehostet: Ostrelle ist als Apache-2.0-Projekt angelegt. Wie das heute geht, steht unter Selbst hosten; was bei einem Ausfall zu tun ist, unter Hilfe bei Ausfällen. Ein öffentlicher Quellcode-Download ist geplant, aber noch nicht verfügbar.