Datenbanken erklärt für nicht-technische Gründer

Datenbanken erklärt: Du verstehst sie bereits, du weißt es nur noch nicht. Eine Datenbank ist eine Tabellenkalkulation mit Superkräften: dieselben Zeilen und Spalten wie in Google Sheets, aber in der Lage, Tausende Nutzer gleichzeitig zu bedienen, Regeln automatisch durchzusetzen und Fragen über Milliarden von Datensätzen sofort zu beantworten. Für einen SaaS-Gründer ist sie die wichtigste Schicht deines Produkts.

Im Restaurant-Modell, wie SaaS funktioniert, ist die Datenbank das Rezeptbuch und das Lager – der einzige Ort, an dem sich irgendetwas gemerkt wird. Hier ist alles, was du darüber verstehen musst, ausgehend von der Tabellenkalkulation, die du schon kennst.

Datenbanken erklärt: Tabellenkalkulation vs. Datenbank, was wirklich anders ist

Stell dir vor, du verfolgst Kunden in Google Sheets: eine Zeile pro Kunde, Spalten für Name, E-Mail, Tarif und Anmeldedatum. Diese Tabelle ist im Wesentlichen eine Datenbanktabelle. Warum also nicht dein SaaS einfach auf einer Tabellenkalkulation betreiben?

Kurz gesagt: Eine Tabellenkalkulation ist ein Notizblock. Eine Datenbank ist das Ablagesystem einer Behörde – organisiert, durchsuchbar, dauerhaft und für Größe gebaut.

Tabellen, Zeilen und Spalten – das Vokabular

Drei Wörter decken die meisten Datenbankgespräche ab, die du je führen wirst:

Eine Tabelle ist wie ein Tabellenblatt und speichert eine Art von Dingen. Dein Produkt hat vielleicht eine Tabelle users für die Menschen, die sich anmelden, eine Tabelle products, eine Tabelle orders, eine Tabelle payments. Eine Tabelle pro Entitätstyp – das ist die Regel.

Eine Zeile ist eine einzelne Instanz dieses Dings. In der Tabelle users ist jede Zeile ein Nutzer. Entwickler nennen Zeilen „Datensätze“.

Eine Spalte ist eine Information über das Ding – die E-Mail, das Anmeldedatum, der Tarif. Jede Spalte legt fest, welchen Datentyp sie enthält: Text, ganze Zahlen, Dezimalzahlen, Wahr/Falsch-Werte, Datumsangaben, eindeutige Kennungen. So setzt die Datenbank Regeln automatisch durch – sie weigert sich schlicht, das Wort „hallo“ in einer Zahlenspalte zu speichern. Deine Tabellenkalkulation würde es gern akzeptieren und stillschweigend deine Berichte kaputtmachen.

Schlüssel: wie Tabellen miteinander verbunden werden

Hier werden Datenbanken wirklich mächtig – und hier endet die Tabellenkalkulations-Analogie.

Jede Tabelle hat einen Primärschlüssel: eine Spalte, meist id genannt, die jede Zeile eindeutig identifiziert. Er muss eindeutig sein, darf nie leer sein und sich nie ändern. Stell ihn dir als Fingerabdruck jedes Datensatzes vor.

Ein Fremdschlüssel (Foreign Key) ist eine Spalte in einer Tabelle, die auf den Primärschlüssel einer anderen zeigt. Deine Tabelle orders wiederholt nicht bei jeder Bestellung Name und E-Mail des Kunden – sie speichert nur eine user_id, die zurück auf die Tabelle users zeigt. Dieser Verweis schafft eine Beziehung: ein Nutzer, viele Bestellungen. Jetzt kannst du fragen „zeig mir jede Bestellung, die dieser Kunde je aufgegeben hat“, und die Datenbank folgt der Verbindung sofort.

Beziehungen sind der Grund, warum du Daten nicht herumkopierst. Würde die E-Mail eines Kunden in jeder Bestellzeile stehen, hieße eine Änderung, jede Bestellung zu aktualisieren – und die Kopien würden unweigerlich auseinanderlaufen. Speichere jeden Fakt einmal, verbinde ihn über Schlüssel, und die Wahrheit bleibt an einem Ort.

Die eine Designregel: Struktur bestimmt, was dein Produkt kann

Hier die Erkenntnis auf Gründerebene. Betrachte zwei Arten, Abonnements zu speichern. Die schlechte packt alles in eine Textspalte in der Zeile des Nutzers: „Pro-Tarif, läuft ab 2025-01-15, bezahlt 99 €.“ Das sieht gut aus – bis du eine Frage stellst. Wie viele Pro-Nutzer haben wir? Wer braucht nächsten Monat eine Verlängerung? Wie hoch ist unser durchschnittlicher Abopreis? Du kannst keine davon beantworten, weil die Fakten in einem Textklumpen gefangen sind.

Die gute Art legt Abonnements in eine eigene Tabelle – Tarif, Preis und Ablaufdatum jeweils in einer eigenen typisierten Spalte, per Fremdschlüssel mit dem Nutzer verknüpft. Dieselbe Information. Jetzt kannst du alles abfragen.

Das ist das Muster im Kleinen: Deine Datenstruktur bestimmt die Fähigkeiten deines Produkts. Deshalb lautet die Arbeitsmethode für Gründer im KI-Zeitalter, die Datenbank zuerst zu entwerfen und alles andere daraus folgen zu lassen.

12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →

Deine Daten überleben deinen Code

Die Realität beim Produktbau: Du wirst das Frontend dreimal neu schreiben, und deine Backend-Logik wird sich ständig weiterentwickeln – aber dein Datenbankschema ist für immer. Facebook hat noch Daten von 2004; das Frontend wurde hundertmal verändert, während die zentralen Tabellen für Nutzer und Beiträge ähnlich geblieben sind.

Deshalb tun Datenbankänderungen auch auf eine Weise weh, wie Codeänderungen es nicht tun. Eine Spalte hinzuzufügen ist leicht. Den Typ einer Spalte zu ändern, sobald sie echte Kundendaten enthält, ist schwer – jeder bestehende Datensatz muss konvertiert werden, und bestehender Code kann brechen. Eine Spalte mit Daten zu entfernen ist beängstigend, weil diese Daten für immer weg sind. Denk gründlich nach, bevor du das Schema anlegst; es später zu ändern ist der teure Teil.

Und das ist, mehr als alles andere, das Argument gegen den Versuch, einer KI zu sagen „bau es einfach“, ohne Datenmodell. Code, den die KI schlecht schreibt, lässt sich in Minuten neu erzeugen. Eine Datenstruktur, die zufällig gewachsen ist – der Kernfehlermodus der Vibe-Coding-Falle –, begleitet dich ein Produktleben lang.

Zwei Dinge, die deine Datenbank speziell für ein SaaS leistet

Sie hält die Daten deiner Kunden getrennt. Ein SaaS bedient viele Unternehmen aus einer Anwendung, deshalb trägt jede Tabelle eine Mandantenkennung, und die Datenbank selbst stellt sicher, dass Firma A nie die Zeilen von Firma B sieht – wie in einem Mehrfamilienhaus: gemeinsame Infrastruktur, getrennte private Räume. Dieser Mechanismus heißt Row-Level Security und verdient eine eigene Erklärung.

Sie erinnert sich verantwortungsvoll. Gut gestaltete Produkte löschen kaum je wirklich etwas – sie markieren Datensätze als gelöscht, damit Fehler rückgängig gemacht werden können und die Historie erhalten bleibt. Jede Tabelle hält fest, wann jede Zeile erstellt und zuletzt aktualisiert wurde. Diese kleinen Gewohnheiten sind der Unterschied zwischen einem Produkt, das du debuggen und prüfen kannst, und einem, das mit den Schultern zuckt.

Die gute Nachricht: Du baust nichts davon von Hand. Moderne Tools geben dir eine professionelle Datenbank mit eingebauter Authentifizierung und Sicherheit – sie ist ein Posten in den echten Kosten, ein SaaS zu bauen, keine Einstellungsentscheidung. Dein Job ist der Teil, den Tools nicht können: zu entscheiden, welche Tabellen es gibt.

Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →

Häufig gestellte Fragen

Was ist eine Datenbank in einfachen Worten?

Strukturierter, dauerhafter Speicher für die Daten deines Produkts – wie eine Tabellenkalkulation, aber in der Lage, Tausende Nutzer gleichzeitig zu bedienen, Regeln automatisch durchzusetzen und Fragen über Milliarden von Zeilen sofort zu beantworten. Alles, was sich dein SaaS merken muss, liegt dort.

Warum kann ich mein SaaS nicht einfach auf einer Tabellenkalkulation betreiben?

Tabellenkalkulationen stoßen bei rund einer Million Zeilen an die Grenze, erlauben nur einen Bearbeiter gleichzeitig und setzen nichts durch – Tippfehler, Duplikate und Inkonsistenzen schleichen sich unbemerkt ein. Eine Datenbank ist automatisiert, validiert und für gleichzeitigen Zugriff gebaut. Tabellenkalkulationen sind für Analysen; Datenbanken sind für Produkte.

Muss ich als nicht-technischer Gründer meine Datenbank selbst entwerfen?

Du entscheidest über die Struktur; die KI schreibt die Umsetzung. Liste die „Dinge“ in deinem Produkt auf – Nutzer, Projekte, Bestellungen –, entscheide, was du über jedes wissen musst und wie sie zusammenhängen. Das ist eine Denkübung über dein Geschäft, keine Programmierübung, und es ist die eine Entscheidung, die später teuer zu ändern ist.

Was sind Primärschlüssel und Fremdschlüssel?

Ein Primärschlüssel identifiziert jede Zeile einer Tabelle eindeutig – der Fingerabdruck jedes Datensatzes. Ein Fremdschlüssel ist eine Spalte, die auf den Primärschlüssel einer anderen Tabelle zeigt und Beziehungen schafft wie „ein Nutzer hat viele Bestellungen“. Über Schlüssel verbindet eine Datenbank Fakten, ohne sie zu kopieren.