SaaS Datenbank Tabellen:Die 10 für jede App

Diese 10 SaaS Datenbank Tabellen tragen 90 % aller Business-Apps: Organisationen, Nutzer, Organisationsmitglieder, deine Haupt-Entität, Kategorien, Beziehungen, Aktivitätsprotokoll, Dateien, Benachrichtigungen und Einstellungen. Du erfindest die Datenbank nicht neu — du klonst diese Struktur, benennst ein paar Dinge um und gehst live. Hier ist der komplette Bauplan, wie die Tabellen zusammenhängen, und der Copy-and-paste-Prompt, mit dem die KI alle Tabellen sauber baut.

Eine Tabelle ist nichts Furchterregenderes als eine strukturierte Tabellenkalkulation: Jede Zeile ist eine Sache (eine Aufgabe, ein Kontakt, eine Rechnung), jede Spalte eine Information zu dieser Sache. Wenn dir das neu ist, fang mit Datenbanken erklärt für nicht-technische Gründer an und komm dann zurück. Der Punkt dieses Beitrags ist einfacher: Du musst Datenbanken nicht verstehen, um eine zu entwerfen. Du musst wissen, welche Tabellen du anlegst — und die sind bei fast jeder SaaS-App gleich.

Die 10 SaaS Datenbank Tabellen, die jede App braucht

Schlechtes Datenbankdesign bringt deine App zum Einsturz, sobald du wächst. Gutes Datenbankdesign sorgt dafür, dass sie einfach funktioniert. Hier ist das Fundament:

Merkst du, wie wenig davon spezifisch für deine Idee ist? 90 % deiner Datenbank sind dieselben wie bei jeder anderen Business-App; 10 % sind deine einzigartige Geschäftslogik. Starte mit den 90 %, baue die 10 %, bring dein Produkt raus.

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

Wie die Tabellen zusammenhängen

Stell dir ein Mehrfamilienhaus vor. Organisationen sind das Hausregister — die Liste der Mietparteien. Nutzer sind die Bewohner. Organisationsmitglieder ist das Wohnungsverzeichnis, das sagt, dass John in Wohnung 5 wohnt und Sarah in Wohnung 12. Von dort ist die Kette logisch: Eine Organisation hat viele Einträge deiner Haupt-Entität (Aufgaben, Kontakte, Rechnungen), an jeden können Dateien angehängt werden, jede Aktion erzeugt einen Eintrag im Aktivitätsprotokoll, und wichtige Ereignisse erzeugen Benachrichtigungen.

Ein konkretes Beispiel — ein einfaches CRM braucht: Organisationen (deine Kunden), Nutzer (Leute, die sich einloggen), Organisationsmitglieder (John arbeitet bei einer Firma, Sarah bei einer anderen), Kontakte (die CRM-Datensätze), Kontakt-Tags (heißer Lead, kalter Lead, Kunde), ein Aktivitätsprotokoll (jede Interaktion), Dateien (an Kontakte angehängte Dokumente), Benachrichtigungen (Hinweise, wenn ein Kontakt aktiv wird) und Einstellungen (Präferenzen pro Organisation). Das war's. Neun Tabellen. Ein komplettes CRM.

Deshalb funktioniert es auch so gut, Tabellen zu entwerfen, bevor du Screens baust — das ganze Argument hinter Database-first-Entwicklung. Screens ändern sich wöchentlich. Diese Struktur ändert sich kaum.

Die Tabellen, die du zum Launch nicht brauchst

Genauso wichtig wie die zehn, die du baust: die, die du weglässt. Ergänze sie später, wenn du sie wirklich brauchst:

• Abrechnung und Abonnements — ergänzen, wenn du bereit bist, Geld zu verlangen
• Teams — ergänzen, wenn Organisationen groß werden
• Integrationen — ergänzen, wenn du andere Tools anbindest
• Berichte — ergänzen, wenn Nutzer Analysen brauchen
• Webhooks — ergänzen, wenn du eine API baust
• Audit-Logs — ergänzen bei Compliance- und Sicherheitsanforderungen

Die Regel: klein anfangen, Tabellen ergänzen, wenn du sie brauchst. Die Datenbank ist nur eine Ebene des Gesamtbilds — die 18 Systeme, die jede SaaS braucht zeigt den Rest —, aber mit Tabellen fängst du an, weil alles andere darauf aufbaut.

Der Copy-and-paste-Prompt, der alle 10 baut

Dieses SQL schreibst du nicht selbst. Du gibst der KI den Bauplan und die Qualitätsanforderungen in einem Prompt:

Create these database tables for a multi-tenant [your app type]:

FOUNDATION: 1. organizations (id, name, slug, settings, tier, is_active, created_at, updated_at) · 2. users (handled by Supabase Auth) · 3. organization_members (organization_id, user_id, role)

CORE FEATURE: 4. [your main entity] with organization_id, your specific fields, audit columns

SUPPORTING: 5. categories (for organising [your main entity]) · 6. files (attachments) · 7. activity_log (tracking all actions) · 8. notifications (user alerts) · 9. settings (preferences)

Requirements: every table needs organization_id (except users) · add indexes on all foreign keys · enable Row-Level Security · use soft deletes (deleted_at column) · add audit columns (created_at, created_by, updated_at, updated_by)

Show me the complete SQL migration.

Die KI erzeugt die Tabellen, sauber verknüpft, mandantenfähig, produktionsreif. Der Anforderungsblock ist keine optionale Dekoration — organization_id in jeder Tabelle und Row-Level Security verhindern, dass Kunde A jemals die Daten von Kunde B sieht.

Das Minimum zum Launch

Bevor du Features baust, prüfe, dass du hast: eine Organisationen-Tabelle, Nutzer (Supabase liefert das), Organisationsmitglieder, deine Haupt-Entität, mindestens eine Möglichkeit, Einträge zu ordnen, ein Aktivitätsprotokoll und Benachrichtigungen. Mit diesen 7 Mindest-Tabellen kannst du bauen und launchen. Den Rest ergänzt du beim Wachsen.

Die meisten Gründer grübeln wochenlang über das Datenbankdesign, als wäre ihre App eine einzigartige Schneeflocke. Ist sie nicht — und das ist die gute Nachricht. Das Fundament ist ein gelöstes Problem. Klone es, passe die 10 % an und stecke deine Energie in den Teil, den nur du bauen kannst.

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

Häufig gestellte Fragen

Brauche ich wirklich alle 10 Tabellen vor dem Launch?

Nein — 7 sind das Minimum: Organisationen, Nutzer, Organisationsmitglieder, deine Haupt-Entität, eine Möglichkeit, Einträge zu ordnen (Kategorien oder Tags), ein Aktivitätsprotokoll und Benachrichtigungen. Dateien, Beziehungen und Einstellungen können mit den Features kommen, die sie brauchen. Abrechnung, Teams, Integrationen, Berichte und Webhooks kommen noch später.

Was bedeutet „Multi-Tenant“ und warum ist das wichtig?

Multi-Tenant heißt: Viele Kunden teilen sich eine App, während jeder nur seine eigenen Daten sieht. Deshalb steht die Organisationen-Tabelle an erster Stelle und deshalb trägt jede Tabelle eine organization_id. Zusammen mit Row-Level Security garantiert das, dass die Datensätze jedes Kunden innerhalb seiner eigenen Wände bleiben — wie Wohnungen in einem Haus.

Kann die KI meine Datenbank wirklich für mich entwerfen?

Ja — wenn du ihr den Bauplan gibst. Füge den obigen Prompt mit deiner Haupt-Entität ein, und die KI liefert die komplette SQL-Migration: Tabellen, Fremdschlüssel, Indizes und Row-Level Security. Was die KI nicht kann: entscheiden, was deine Haupt-Entität ist. Das ist eine Produktentscheidung, keine technische.

Was ist die „Haupt-Entität“ meiner App?

Das eine, was deine App verwaltet. Aufgabenverwaltung → Aufgaben. CRM → Kontakte. Rechnungsstellung → Rechnungen. Buchung → Termine. E-Commerce → Produkte. Wenn du es nicht in einem Wort benennen kannst, hast du dein Produkt noch nicht scharf genug definiert — kläre das, bevor du die Datenbank anfasst.