Funktionen · Datenbank

Eine echte Datenbank, schon angebunden.

Verwaltetes Postgres – ein Datenbankkonto müssen Sie nicht eröffnen. In einem kostenpflichtigen Tarif sind Ihre verwalteten Datenbanken ein gemeinsames Kontingent für alle Ihre Apps: Fordern Sie eine an, wenn Sie bereitstellen, und eine einzige Aktion legt sie an, verbindet sie und startet erst danach den Build, sodass die Migrationen Ihres Builds die Datenbank schon im allerersten Build erreichen. Der Free-Tarif enthält eine Datenbank für Ihre App: mit deren erster Bereitstellung, wenn der Free-Tarif den Servercode der App ausführt, andernfalls, sobald die App online ist. Die Datenbank bleibt erhalten, solange die App online ist.

Dokumentation lesenAgent einrichten

Was Ihr Agent aufruft

  • deploy
  • databaseCreate
  • databaseStatus
  • databaseReconcile
claude · ~/franks-kitchenBeispiel

Take my restaurant app live, with a database.

tofu · setFramework nextjs

confirmed

tofu · deploy database: true

managed database ready · Postgres

DATABASE_URL + 5 more · write-only

build ready

HTTP 200 · publicly reachable

Live at https://franks-kitchen-3f9a1c07b2e4.trytofu.app

Eine Aktion

Anlegen, verbinden, dann bauen. In dieser Reihenfolge, in einem Schritt.

Wählen Sie eine Datenbank im Bereitstellungsschritt – ein Kontrollkästchen im Dashboard, database: true von Ihrem Agent, deploy --database aus der Shell. Jede Datenbank zählt zu den Datenbanken, die Ihr Tarif umfasst, ist also nie voreingestellt: Nur Ihr Ja – für diese App – legt eine an.

  1. Datenbank anlegen

    Eine eigene Postgres-Datenbank in der Region Ihrer Wahl: Americas, EMEA oder APAC.

  2. Warten, bis sie bereit ist

    Bis zu 2 Minuten. Ist sie bis dahin nicht verbunden, wird kein Build eingereicht, und die Antwort nennt den Zustand, in dem sie sich befindet.

  3. Verbindungseinstellungen schreiben

    In das Hosting-Projekt Ihrer App – die Verbindung als nur schreibbare Werte, daneben das öffentliche Zertifikat der Datenbank. Bei der ersten Bereitstellung legt Tofu dieses Projekt hier an.

  4. Build starten, wenn die Datenbank bereitsteht

    Erst jetzt. Führt Ihr Build Ihre Migrationen aus, laufen sie schon im allerersten Build auf der neuen Datenbank – bevor die App online geht.

Eine Datenbank, die Sie früher auf der Seite „Datenbank“ angelegt haben, wird von Ihrer nächsten Bereitstellung genauso verbunden – bevor diese Bereitstellung den Build startet.

Was Ihre App erhält

Eingebunden, nie angezeigt.

Tofu schreibt die Verbindungseinstellungen direkt in die sensible, nur schreibbare Umgebung Ihres Hosting-Anbieters – und daneben das öffentliche Zertifikat der Datenbank als gewöhnlichen Wert. Tofu selbst speichert nur die Namen und sonst nichts; ein Service-Role-Schlüssel wird nicht verwendet.

VariableWer sie erhält
DATABASE_URLJede App – die Verbindungszeichenfolge, über den Transaction-Pooler des Anbieters.
SUPABASE_URLJede App – die öffentliche Adresse des Datenbankprojekts.
SUPABASE_ANON_KEYJede App – ihr öffentlicher Schlüssel.
SUPABASE_CA_CERTJede App – das öffentliche Root-Zertifikat des Datenbankservers, damit Ihr Code prüfen kann, dass er mit Ihrer Datenbank spricht. Kein Secret.
‹prefix›SUPABASE_URL‹prefix›SUPABASE_ANON_KEY‹prefix›SUPABASE_PUBLISHABLE_KEYApps mit Next.js (NEXT_PUBLIC_), Vite (VITE_) und Astro (PUBLIC_) erhalten noch einmal die öffentliche Adresse und den Schlüssel – unter dem Namen, den ihr Browser-Bundle liest.

Alle anderen Presets – auch Server-Apps mit Python, Go oder JavaScript – erhalten nur die serverseitigen Namen, weil Tofu kein Browser-Präfix errät.

Bestätigen Sie das Framework Ihrer App, bevor die Datenbank verbunden wird: Die Browser-Namen richten sich in diesem Moment nach dem Framework und werden später nicht ergänzt.

Im Free-Tarif gilt: Läuft Ihre App im gemeinsamen statischen Hosting von Tofu, greifen ihre Seiten direkt aus dem Browser auf die Datenbank zu. Sie erhält dann nur die öffentliche Adresse und den Schlüssel unter VITE_, aber kein DATABASE_URL und kein Zertifikat. Andernfalls erhält sie diese wie in einem kostenpflichtigen Tarif.

Ihr Schema

Ihre Migrationen, ausgeführt von Ihrem Build.

Die Datenbank startet absichtlich leer: Das Schema gehört dem Repository, das es definiert. Tragen Sie Ihre Migration in den Build-Befehl ein, und jede Bereitstellung bringt das Schema gleich mit – keine Zugangsdaten werden irgendwohin kopiert, und das Schema kann nicht hinter dem Code zurückbleiben, mit dem es ausgeliefert wurde.

Ab dem 30.10.2026 vergibt Supabase für eine neue Tabelle in public den Rollen, die die Seiten der App verwenden, nicht mehr automatisch Rechte. Deshalb muss die Migration, die eine Tabelle anlegt, die Rechte selbst vergeben: select an anon nur für das, was nicht angemeldete Besucher lesen dürfen, select, insert, update, delete an authenticated und dieselben Rechte an service_role, wenn Servercode sie nutzt. Eine View braucht ihr eigenes grant select und muss mit security_invoker = true angelegt werden, damit die Zeilen darunter weiterhin durch ihre Zugriffsregeln geschützt bleiben.

Wenn eine Migration, die Ihr Build ausführt, fehlschlägt, schlägt der Build fehl, und die vorherige Version bleibt weiterhin online. Anweisungen, die bereits angewendet wurden, bleiben angewendet.

Wo Ihre Seite „Datenbank“ es angibt, wendet Tofu die Dateien in Ihrem Ordner supabase/migrations vor jedem Update selbst an. Wenn eine davon fehlschlägt, stoppt Tofu dieses Update vor dem Build, und eine bereits online stehende Version läuft weiter.

Die Struktur wandert mit, die Daten nicht. Die Migrationen, die Ihr Build ausführt, erreichen diese Datenbank. Zeilen, die nur auf Ihrem Rechner liegen, erreichen sie nicht – es sei denn, eine Migration fügt sie ein.

Im Free-Tarif gilt: Wenn Ihre App auf dem gemeinsamen statischen Hosting von Tofu liegt, führt der Build der App keine Migrationen aus. Die Tabellen der App werden deshalb außerhalb des Builds angelegt, wie die Seite „Datenbank“ es für Ihre App zeigt. Andernfalls kann der Build sie ausführen, wie in einem kostenpflichtigen Tarif.

package.jsonprisma
{
  "scripts": {
    "build": "prisma migrate deploy && next build"
  }
}
Drizzle: drizzle-kit migrate. Supabase CLI: supabase db push --db-url "$DATABASE_URL". Reines SQL: der Runner, den Ihr Repository bereits hat.

Ihre Daten ansehen

Ein Tabelleneditor, keine SQL-Konsole.

Die Seite „Datenbank“ listet die Tabellen in Ihrem public-Schema und blättert durch ihre Zeilen – ohne jemandem eine Konsole in die Hand zu geben.

  • Lesen

    Jede Tabelle in Ihrer Datenbank, 25 Zeilen pro Seite

    Angezeigt werden die eigenen Schemas Ihrer App und die, die der Datenbankdienst für sie führt – darunter ihre Anmeldekonten, nur lesbar, mit verborgenen Passwörtern und Token, bis Sie „Anzeigen“ drücken. Dazu kommen der Typ jeder Spalte, der Primärschlüssel und die Angabe, ob Row-Level-Security aktiv ist. Eine Zeilenanzahl ist eine Schätzung des Planers, und das wird auch so angegeben.

  • Schreiben

    Aus, bis Sie es einschalten

    Schreiben ist ein Schalter pro App. Jedes Einfügen, Ändern oder Löschen betrifft dann eine Zeile und wird einzeln bestätigt – eine Zeile, die sich inzwischen geändert hat, wird gemeldet, nicht überschrieben.

  • Nie

    Keine Schemaänderungen, kein SQL, kein Export

    Der Editor kann nichts anlegen, ändern oder löschen, und Zeilen verlassen ihn seitenweise – auf Ihrem Bildschirm.

  • Nur für Sie

    In Ihrem Dashboard, nicht in Ihrem Agent

    Kein Agent kann Zeilen lesen oder schreiben. Der Editor verbindet sich mit der Admin-Rolle der Datenbank selbst; deshalb begrenzt ihn Row-Level-Security nicht – und das Panel sagt das auch.

Bleibt bei Ihnen

Ihre Daten, und Ihr Weg hinaus.

Umzug in Ihre eigene Supabase-Organisation

Auf Anfrage zieht die Datenbank in eine Supabase-Organisation um, die Ihnen gehört – eine Übertragung, die mit Ihnen abgestimmt und geprüft wird, in derselben Region, nicht per Knopfdruck.

Der Verbindungsstring, wenn Sie ihn brauchen

Für ein lokales Werkzeug oder eine einmalige Datenkorrektur baut „Datenbankschlüssel anzeigen“ ihn für Sie als Eigentümer neu zusammen und protokolliert das. Kein Agent kann ihn erhalten.

Gelöscht, wenn Sie es sagen

Das Löschen einer Datenbank ist Sache des Eigentümers: Sie tippen den Namen der App ein, und die Datenbank, ihr Schema und ihre Daten werden entfernt; beim Löschen wird keine Kopie angelegt.

Noch nicht umgesetzt

  • Browser-Namen nur für Next.js, Vite und Astro. Andere Presets erhalten die serverseitigen Namen, und noch keine Python- oder Go-App wurde durchgängig gegen eine verwaltete Datenbank betrieben.

  • Keine Passwortrotation. Nichts im Dashboard ändert das Datenbankpasswort; bei Verdacht auf ein Leck ist das ein Fall für den Support.

So verhält sich diese Datenbank

  • Tofu entwirft keine eigenen Tabellen und hat keine SQL-Konsole. Die Tabellen Ihrer App stammen aus ihren eigenen Migrationen: Wo Ihre Seite „Datenbank“ es angibt, wendet Tofu die Dateien in supabase/migrations vor jedem Update an; andernfalls werden sie von einem Migrationsschritt in Ihrem Build angewendet oder von Ihrem eigenen Rechner mit dem Datenbankschlüssel. Die SQL-Konsole fehlt aus Prinzip: Hochgeladener Quellcode ist eine nicht vertrauenswürdige Eingabe, und ein einziger Betreiberzugang würde alle verwalteten Datenbanken abdecken.

  • Lokale Daten bleiben lokal. Zeilen, die nur auf Ihrem Rechner existieren, erreichen diese Datenbank nie, es sei denn, eine Migration fügt sie ein.

  • Keine Tabellen oder Policies von Tofu selbst. Die Datenbank startet leer; Ihre Migrationen legen die Tabellen an und die Row-Level-Security-Policies, auf die sich Ihre App verlässt.

  • Wie viele Datenbanken Sie erhalten, hängt von Ihrem Tarif ab. Die Zahl gilt für alle Ihre Apps zusammen. Die Preisseite listet, welche Tarife Datenbanken enthalten und wie viele.

Einen Prompt einfügen. In 10 Minuten online.

Ihre App samt Datenbank, Ihre Domain und Ihre Anmeldung – in etwa 10 Minuten mit dem Agenten, den Sie schon nutzen.

Kostenlos starten