Kaum ist die erste Idee skizziert, steht sie im Raum: die Datenbank. PostgreSQL, Supabase, Mongo, „irgendwas mit Prisma“. Dabei ist die wichtigere Frage selten „Welche Datenbank?“, sondern: Welche Daten sind wirklich dynamisch?
Für viele MVPs lautet die ehrliche Antwort: fast keine. Und das ist eine Chance.
Die falsche Frage
„Welche Datenbank passt zu unserem Stack?“ klingt nach einer technischen Entscheidung. Meistens ist es eine Gewohnheit. Wir haben gelernt, dass Anwendungen eine Datenbank haben. Also bekommt die neue Anwendung auch eine – bevor klar ist, ob sie gebraucht wird.
Die nützlichere Frage ist: Welche Information muss sich ändern, ohne dass jemand Code deployt?
Bei einem Portfolio, einem Blog, einer Marketing-Seite oder einer Dokumentation ist die Antwort oft: der Inhalt. Und Inhalte lassen sich hervorragend in Git versionieren. Ein Commit ist ein Datensatz, ein Pull Request ist ein Review, ein Merge ist eine Veröffentlichung. Die Datenbank wäre hier eine zweite Quelle der Wahrheit, die mit der ersten synchron gehalten werden müsste.
Was ein MVP wirklich braucht
Ein MVP soll eine Hypothese testen. Nicht die Infrastruktur für fünf Jahre aufbauen. Für viele erste Versionen reichen:
- statisch gerenderte Seiten aus Dateien,
- ein Formular, das eine E-Mail verschickt,
- eine Suche, die zur Buildzeit einen Index erzeugt,
- ein paar interaktive Inseln für Filter, Menüs oder Validierung.
Das ist kein Kompromiss. Es ist oft die schnellere und robustere Variante. Statisches HTML ist schwer kaputtzukriegen, braucht keine Datenbankmigration und lässt sich weltweit über ein CDN ausliefern.
Wann eine Datenbank wirklich Sinn ergibt
Es gibt klare Signale, ab denen eine Datenbank die richtige Antwort ist:
- Mehrere Nutzer schreiben gleichzeitig. Buchungen, Bestellungen, Kommentare, kollaborative Dokumente.
- Transaktionen sind fachlich notwendig. Ein Lagerbestand darf nicht negativ werden, eine Zahlung nicht doppelt gebucht.
- Daten müssen in Echtzeit abgefragt werden. Dashboards mit Live-Werten, Benachrichtigungen, Anwesenheiten.
- Authentifizierung und Rollen dazukommen. Sobald es Konten gibt, braucht es eine verlässliche Quelle für Identitäten und Berechtigungen.
- Historische Ereignisse ausgewertet werden. Nicht nur der aktuelle Zustand, sondern jede Änderung.
- Hintergrundjobs Daten verarbeiten und Zustände über mehrere Schritte halten müssen.
Das sind echte Anforderungen. Sie kommen aber selten alle am ersten Tag.
Was eine Datenbank kostet
Eine Datenbank ist kein neutraler Baustein. Sie bringt Betrieb mit:
- Schema und Migrationen,
- Backups und Wiederherstellung,
- Verbindungsmanagement und Pooling,
- Authentifizierung, Rollen und Row Level Security,
- Monitoring, Alarme und Fehlerbilder,
- Datenschutz, Aufbewahrung und Löschkonzepte,
- eine zweite Umgebung, die gepflegt werden muss.
Das ist beherrschbar. Aber es ist Arbeit, die man bewusst eingehen sollte – nicht versehentlich, weil ein Template sie mitbringt.
Ein Beispiel aus diesem Portfolio
Diese Seite hat keine Datenbank. Projekte und Artikel liegen als MDX in Git. Die Suche wird beim Build mit Pagefind erzeugt. Das Kontaktformular validiert serverseitig und verschickt eine E-Mail; es speichert keine Anfrage.
Das ist keine religiöse Überzeugung. Es ist die kleinste Architektur, die die aktuellen Anforderungen erfüllt. Wenn später ein Dashboard, gespeicherte Anfragen oder ein Newsletter dazukommen, kann eine Datenbank ergänzt werden. Damit das nicht zum Umbau wird, ist die Content-Schicht hinter einem Adapter gekapselt:
interface ContentRepository {
getProjects(lang: Lang): Promise<Project[]>;
getProject(lang: Lang, slug: string): Promise<Project | null>;
getArticles(lang: Lang): Promise<Article[]>;
getArticle(lang: Lang, slug: string): Promise<Article | null>;
}Heute liest die Implementierung Dateien. Morgen könnte sie Supabase oder ein CMS lesen. Die Seiten kennen nur das Interface.
Die pragmatische Reihenfolge
- Schreibe auf, welche Daten sich ändern müssen. Nicht welche Tabellen es geben könnte.
- Starte mit der einfachsten Quelle, die die Anforderung erfüllt. Oft ist das eine Datei, ein Formular und ein E-Mail-Postfach.
- Kapsele den Zugriff. Ein Adapter ist billiger als eine Migration.
- Füge die Datenbank hinzu, wenn ein Feature sie erzwingt. Nicht, wenn ein Template sie vorschlägt.
Eine Datenbank ist ein Werkzeug. Kein Abzeichen. Und ein MVP, das ohne sie auskommt, ist nicht weniger professionell – es hat nur eine Entscheidung weniger zu bereuen.