Links eine Website-Datei als Symbol mit Pfeil zum Browser, rechts eine Datenbank mit komplexem Server-Aufbau, beide unter einer Waage.

Wann eine Website eine Datenbank braucht, und wann nicht

Es hält sich hartnäckig die Annahme, dass eine ernsthafte Unternehmens-Website eine Datenbank braucht. Ein dynamisches System. Ein CMS, das Inhalte zur Laufzeit zusammenbaut. Diese Annahme stimmt seltener, als sie ausgesprochen wird.

Wofür eine Datenbank wirklich nötig ist

Eine Datenbank ist sinnvoll, wenn Inhalte sich häufig ändern, viele Personen parallel pflegen oder die Inhalte aus mehreren Quellen kombiniert werden müssen. Beispiele: Ein Shop mit täglich wechselnden Preisen, ein Stellenportal mit Bewerbungen, ein Kundenportal mit Login.

Sie ist auch nötig, wenn Inhalte personalisiert werden müssen, also Besucher A etwas anderes sieht als Besucher B.

In all diesen Fällen ist die Datenbank kein Selbstzweck, sondern eine Notwendigkeit, die aus der Aufgabe folgt.

Wofür sie nicht nötig ist

Eine Marketing-Site mit Hero, Service-Seiten, Team-Seite, Blog und Kontaktformular braucht keine Datenbank. Auch wenn das CMS-Marketing seit zwanzig Jahren etwas anderes erzählt.

Die Inhalte ändern sich vielleicht alle paar Wochen. Sie sind für alle Besucher gleich. Sie kommen aus einer einzigen Quelle, dem internen Team. Es gibt keinen technischen Grund, jede Anfrage durch eine Datenbank, einen Anwendungs-Server und eine Template-Engine zu schicken.

Was passiert, wenn man trotzdem eine nimmt

Sicherheits-Updates für Datenbank, Server, Framework und Plugins. Pflege der Plugin-Kompatibilität bei jedem Major-Update. Backups. Performance-Optimierung, weil Datenbank-Aufrufe langsamer sind als Dateien lesen. Ein Cache, der unter bestimmten Bedingungen veraltet ist.

All das ist Aufwand, der ohne klaren Gegenwert entsteht. Bei einer Site, deren Inhalte sich monatelang nicht ändern, zahlt ihr für Komplexität, die ihr nicht braucht.

Was die Alternative leistet

Eine statisch generierte Site liefert HTML aus, fertig. Keine Datenbank, kein Server-Side-Rendering zur Laufzeit, kein Plugin-Stack. Inhalte werden im Build-Prozess in HTML übersetzt und ab dann nur noch ausgeliefert.

Performance ist deutlich besser, Sicherheits-Angriffsfläche kleiner, Wartung minimal. Die Einschränkung: Bei jeder Inhalts-Änderung muss neu gebaut werden. Was wie ein Nachteil klingt, ist im Alltag oft ein Sekunden-Vorgang.

Fazit

Die Frage ist nicht “statisch oder dynamisch”, sondern “was braucht meine Aufgabe wirklich”. Wer aus Reflex zur Datenbank greift, baut Komplexität, die er später pflegen muss. Wer einschätzen will, was zur eigenen Site passt, kann mich ansprechen.

Lassen Sie uns sprechen

Datenschutzerklärung

Kennenlernen
Kontaktaufnahme unverbindlich
Festnetz
06692 8069441
Mobil
+49 173 4447719