Datenbank in deine App einbauen (ohne dass du später Daten verlierst)

Um eine Datenbank in deine App einzubauen, wählst du eine verwaltete relationale Datenbank (meist Postgres), legst den Verbindungsstring als Geheimnis auf dem Server ab, erstellst eine Tabelle pro Art von Daten, die deine App speichert, und lässt dein Backend — niemals den Browser — darauf lesen und schreiben. Wenn du mit einem KI-App-Builder arbeitest, reicht meist der Satz „Speichere das in einer Datenbank“, und der Agent richtet Tabellen und Code ein. Deine Aufgabe ist, die Daten klar zu beschreiben und zu prüfen, ob sie wirklich dauerhaft gespeichert werden.

Dieser Leitfaden zeigt, wann du eine Datenbank brauchst, welche Optionen es gibt, wie du deine Daten beschreibst und welche Fehler zu verlorenen oder offengelegten Daten führen.

Wann deine App eine Datenbank braucht

Eine Datenbank brauchst du, wenn deine App sich etwas merken muss, nachdem die Seite geschlossen wurde, oder Daten zwischen Menschen teilen soll. Typische Anzeichen:

• Besucher schicken etwas ab: ein Formular, eine Anmeldung, eine Buchung, eine Bestellung
• Nutzer haben Konten mit eigenen gespeicherten Inhalten
• Ein Admin muss sehen oder bearbeiten können, was andere erstellt haben
• Du willst Auswertungen oder Zählungen über die Zeit

Für eine statische Seite, auf der alle denselben Inhalt sehen, etwa ein Portfolio oder eine einfache Landingpage, brauchst du keine. Wenn dir unklar ist, was eine Datenbank eigentlich ist, lies zuerst was ist eine Datenbank.

Deine Optionen

Für die meisten kleinen und mittleren Web-Apps ist eine relationale Datenbank wie Postgres der richtige Standard. Sie kann gut mit Beziehungen umgehen (ein Kunde hat viele Bestellungen), hält Daten konsistent und lässt dich später Fragen mit SQL beantworten. Eine verständliche Erklärung findest du unter was ist Postgres.

Beschreibe deine Daten, bevor du baust

Das Nützlichste, was du tun kannst, ist aufzuschreiben, welche Dinge deine App speichert und wie sie zusammenhängen. Du brauchst dafür keine Datenbank-Fachsprache. Bei einer Buchungs-App sieht das so aus:

• Kunden: Name, E-Mail, Telefon
• Leistungen: Name, Dauer, Preis
• Buchungen: welcher Kunde, welche Leistung, Startzeit, Status (ausstehend, bestätigt, storniert)

Das sind drei Tabellen. „Welcher Kunde“ und „welche Leistung“ werden zu Verknüpfungen (Fremdschlüssel) zwischen ihnen. Das früh richtig hinzubekommen ist wichtiger als jede Technologiewahl, denn die Struktur von Daten, die bereits echte Zeilen enthalten, zu ändern ist schwerer als ein Seitenlayout anzupassen.

Einige Faustregeln:

• Eine Tabelle pro Art von Ding. Bestellungen gehören nicht als Textfeld in den Kundendatensatz.
• Jede Zeile bekommt eine ID und einen Erstellzeitpunkt. Beides brauchst du später.
• Saubere Datentypen verwenden. Datumswerte als Datum, Geldbeträge als ganze Cent oder Dezimalzahl, nicht als Text.
• Pflichtfelder als Pflicht markieren. Lass die Datenbank schlechte Daten ablehnen, nicht nur das Formular.

Beispiel-Prompts

Fang mit einer Funktion nach der anderen an, statt ein ganzes Schema auf einmal zu schicken:

Füge dieser App eine Datenbank hinzu. Erstelle eine Tabelle „bookings“ mit Kundenname, E-Mail, Leistung, Startzeit und Status (ausstehend, bestätigt, storniert; Standard: ausstehend). Speichere die Einsendungen des Buchungsformulars darin, zeige eine Erfolgsmeldung und füge eine Admin-Seite hinzu, die Buchungen von neu nach alt auflistet.

Dann erweitern:

Füge eine Tabelle „services“ hinzu (Name, Dauer in Minuten, Preis in Cent). Ersetze das freie Textfeld für die Leistung bei Buchungen durch eine Verknüpfung mit services und übertrage vorhandene Buchungen, ohne etwas zu löschen.

Und absichern:

Stelle sicher, dass alle Datenbank-Lese- und Schreibzugriffe auf dem Server passieren. Der Browser darf den Verbindungsstring der Datenbank niemals erhalten. Prüfe E-Mail und Startzeit auf dem Server, bevor du etwas einfügst.

Schritt für Schritt

1. Liste deine Daten wie oben: Dinge, Felder, Verknüpfungen zwischen ihnen.
2. Erstelle die Datenbank. In einem KI-Builder fragst du im Chat danach. Anderswo legst du eine verwaltete Postgres-Instanz an und kopierst den Verbindungsstring.
3. Speichere den Verbindungsstring als Geheimnis (eine Umgebungsvariable auf dem Server), niemals im Code. Siehe Umgebungsvariablen und Geheimnisse.
4. Erstelle die Tabellen. Nutze Migrationen, also versionierte Skripte, die das Schema ändern, damit Änderungen wiederholbar und rückgängig zu machen sind.
5. Baue die Server-Routen, die Zeilen anlegen, lesen, aktualisieren und löschen (CRUD). Der Browser ruft diese Routen auf; er spricht nie direkt mit der Datenbank.
6. Verbinde die Oberfläche mit diesen Routen: Formulare, die speichern, Listen, die laden, Leerzustände, wenn noch nichts da ist.
7. Prüfe die Speicherung. Schick etwas ab, lade die Seite neu, öffne sie in einem anderen Browser. Wenn die Daten nicht da sind, wurden sie nicht in der Datenbank gespeichert.
8. Prüfe den Zugriff. Melde dich als zweiter Nutzer an und kontrolliere, ob du die Daten des ersten Nutzers weder sehen noch ändern kannst.
9. Veröffentliche und teste danach erneut unter der echten URL, denn die veröffentlichte App kann eine andere Verbindung nutzen als deine Vorschau.

Häufige Fehler

• Im Browser speichern und glauben, es sei gespeichert. localStorage funktioniert scheinbar, bis jemand die App auf einem anderen Gerät öffnet. Teste immer in einem zweiten Browser.
• Den Verbindungsstring in den Frontend-Code schreiben. Jeder kann Frontend-Code lesen. Damit bekommt er deine gesamte Datenbank.
• Keine Zugriffsprüfung. „Zeige meine Bestellungen“ muss auf dem Server nach dem angemeldeten Nutzer filtern, nicht in der Oberfläche. Das ist das häufigste Sicherheitsloch bei KI-gebauten Apps; unsere Sicherheits-Checkliste für KI-gebaute Apps behandelt es.
• Destruktive Schema-Änderungen. Wenn du „benenne die Tabelle um“ oder „ändere die Struktur“ sagst, kann sie gelöscht und neu angelegt werden. Gibt es echte Daten, sag: „übertrage die vorhandenen Zeilen, lösche nichts“.
• Dateien in der Datenbank speichern. Bilder und PDFs gehören in einen Dateispeicher; in der Tabelle steht nur ihre URL oder ihr Schlüssel. Siehe wie du Datei-Uploads hinzufügst.
• Keine Backups. Finde heraus, wie deine Plattform Daten sichert und wie du sie wiederherstellst, bevor du Kunden hast.

Checkliste

• Jede Art von Ding hat eine eigene Tabelle mit ID und Erstellzeitpunkt
• Pflichtfelder und Datentypen werden von der Datenbank durchgesetzt
• Der Verbindungsstring liegt nur in Geheimnissen auf dem Server
• Alle Lese- und Schreibzugriffe laufen über Server-Routen
• Jeder Nutzer kann nur seine eigenen Zeilen lesen und ändern
• Die Daten überstehen ein Neuladen und erscheinen in einem anderen Browser
• Schema-Änderungen laufen über Migrationen und behalten vorhandene Zeilen
• Du weißt, wie Backups und Wiederherstellung funktionieren
• Die Live-App wurde nach der Veröffentlichung getestet

Eine Datenbank in Mythex hinzufügen

In Mythex kann jedes Projekt eine eigene dedizierte Postgres-Datenbank bekommen, sowohl auf Free als auch auf Pro. Du klickst meist keinen separaten Button zum Anhängen: Frag im Chat („speichere Warteliste-E-Mails in einer Datenbank“) oder tippe /database. Die Verbindungsdaten werden dann in den Arbeitsbereich und deine veröffentlichte App eingesetzt. In den Projekteinstellungen siehst du, ob eine Datenbank aktiv ist.

Die Datenbank schläft nach 5 Minuten Inaktivität und wacht bei der nächsten Anfrage auf. Die Nutzung der veröffentlichten App wird für die Zeit berechnet, in der sie tatsächlich wach war, aus demselben Credit-Guthaben, das du fürs Bauen nutzt. Wenn du eine Datenbank erst nach dem Veröffentlichen hinzufügst, veröffentliche erneut, damit die Live-App sie übernimmt.

Siehe Datenbank und das Rezept CRUD-App bauen in der Dokumentation. Zur Anmeldung für nutzerbezogene Daten lies wie du Anmeldung in deine App einbaust.

Fragen