Ein Dienst lässt sich in der Projektkonfiguration mit einer Zeile aktivieren. Danach legt die CLI einen Ordner mit Startcode an und lädt ihn auf die Infrastruktur. Arbeit, die bisher auf einer zweiten Plattform lief, bleibt damit im selben Projekt wie die Daten. Supabase bietet das als Compute in einer privaten Alpha an, zunächst in us-west-2. Neu ist daran wenig. Der Punkt ist der kürzere Weg zwischen Rechenprozess und Datenbank.
Lager und Werkstatt lagen getrennt. Das Lager stand beim Datenbankanbieter, die Werkstatt irgendwo anders. Jede Abfrage, jeder Nachschlag lief über eine Strecke, die niemand kontrolliert. Compute stellt die Werkstatt neben das Regal. Der Dienst greift direkt auf die Daten zu, statt sie über das Netz zu holen.
Wo Edge Functions nicht mehr reichen
Edge Functions sind für kurze, klar umrissene Aufgaben gebaut: Ein Request kommt an, eine Antwort geht raus, fertig. Länger dauernde Aufgaben, mehr Speicher oder eine andere Sprache passen nicht hinein. In der Ankündigung berichten Entwickler genau davon. Ihre Arbeit passt nicht in eine Edge Function, weil sie mehr CPU oder Speicher braucht, länger als 400 Sekunden läuft – etwa ein KI-Agent, der mehrere Schritte koordiniert – oder in einer anderen Sprache geschrieben ist.
Die übliche Antwort war eine zweite Plattform: ein Container-Dienst, ein Job-Runner, irgendetwas mit eigenem Deployment, eigenen Logs und eigenen Zugangsdaten. Zwei Systeme, getrennt überwacht. Im Fehlerfall suchst du erst einmal auf der falschen Seite. Der Datenbankzugriff läuft über das öffentliche Netz, mit allen Zwischenschritten. Das funktioniert, kostet aber Zeit und Aufmerksamkeit an Stellen, an denen nur eine Query nötig wäre.
Was ein Compute-Dienst im Projekt ist
Jeder Dienst erhält eine vollständige Linux-Umgebung. Zur Wahl stehen 2 GB Arbeitsspeicher mit einer vCPU oder 4 GB mit zwei vCPUs. Du legst außerdem fest, ob der Dienst öffentlich ist und eine URL bekommt oder privat bleibt. Als Laufzeit gibt es Node, Deno oder ein beliebiges Dockerfile. Damit bist du nicht auf eine Sprache festgelegt und kannst bestehende Container übernehmen.
Die Beispiele aus der Ankündigung zeigen das Spektrum: ein KI-Agent, der Teilaufgaben anstößt und koordiniert; eine API oder ein Webdienst in einer beliebigen Sprache, konfiguriert über ein Dockerfile; ein dauerhafter Job-Prozessor, der Aufgaben aus Postgres zieht, etwa OpenWorkflow; ein Datenabgleich oder ein Embedding-Backfill, der über Stunden läuft; oder ein WebSocket-Dienst für Anwendungen, bei denen Verzögerung zählt, etwa Sprachagenten.
Zwei Details werden leicht übersehen. Jeder Dienst erhält automatisch die Secrets des Projekts; du verteilst sie nicht separat. Und die Logs stehen auf der Compute-Seite im Dashboard, also dort, wo du ohnehin nachsiehst. Die Werkstatt hat damit denselben Schlüsselbund und dasselbe Notizbuch wie das Lager. Das reduziert Reibung, verschiebt aber Verantwortung: Wer Secrets im Projekt ändert, ändert sie für alle Dienste.
Von der Konfiguration zum laufenden Dienst
Der Ablauf bleibt schlicht. Du brauchst die CLI in Version 2.120.0 oder neuer. Zuerst trägst du compute = true unter [experimental] in supabase/config.toml ein. Danach erzeugt supabase compute new einen Dienst; du wählst Laufzeit, Größe und Sichtbarkeit. Ersetze den Startcode im Ordner supabase/compute/ durch deinen eigenen. supabase compute push lädt ihn hoch.
Die Einstellungen eines Dienstes sind nur wenige Zeilen in der config.toml. Ein Coding-Agent kann sie schreiben und den Dienst selbst deployen, wenn man ihn auf die Compute-Dokumentation verweist. Die Management API bietet zusätzlich Alpha-Endpunkte zum Deployen, Auflisten und Löschen von Diensten. Wer seine Infrastruktur ohnehin automatisiert, kann das ohne Klicks im Dashboard erledigen.
Die Messung von Dreambase
Eine Zahl aus der Ankündigung ist aufschlussreich. Dreambase hat seinen Datenagenten testweise auf Compute verschoben. Die Queries an Postgres brauchten im Median 2,9 Millisekunden, aus einer anderen Region waren es 65 Millisekunden. Das ist kein Benchmark für die Produktqualität, sondern eine Aussage über Entfernung. Gut 60 Millisekunden Unterschied pro Query klingen harmlos. Bei zwanzig oder fünfzig Abfragen hintereinander summiert sich die Wartezeit, und ein Ablauf stockt.
Rechenzeit ist das eine. Der Weg zwischen Rechnung und Daten ist oft der teurere Teil. Ein Agent, der in einer Schleife den Zustand aus der Datenbank liest, entscheidet und das Ergebnis zurückschreibt, braucht kurze Umlaufzeiten. Jede Millisekunde dazwischen wird bei jedem Durchlauf erneut bezahlt.
Grenzen der privaten Alpha
Die Ankündigung nennt die Grenzen klar. Compute ist zur Evaluierung gedacht, nicht für den Produktivbetrieb, und kann sich ändern oder eingestellt werden. Derzeit gibt es das Angebot nur für Projekte in us-west-2. Ein Dienst kann jederzeit neu starten. Langlaufende Arbeit muss deshalb in Postgres liegen, nicht im Speicher des Dienstes. Autoscaling, GPUs und dauerhafte Festplatten gibt es nicht.
Ein Detail hat Folgen: Jeder Dienst bekommt sämtliche Secrets des Projekts, nicht nur die, die er braucht. Die Trennung zwischen Diensten läuft damit über das Netzwerk, nicht über Berechtigungen. Wer einen Dienst kompromittiert, hält den ganzen Schlüsselbund. Für eine Alpha ist das nachvollziehbar. Vor einem Produktivbetrieb wäre es eine der ersten Fragen.
Im Leerlauf verhalten sich Dienste unterschiedlich. Öffentliche Dienste werden bei Inaktivität angehalten, private laufen weiter. Das ist eine Kostenfrage und eine Frage der Erwartung: Ein Dienst, der nach einer Ruhephase erst wieder hochkommen muss, passt nicht überall. Sandboxes für KI-Agenten sind nicht Teil der Alpha; wer sie braucht, soll das melden. Der Zugang läuft über eine Warteliste, die Projekte in us-west-2 bevorzugt.
Folgen für den Betrieb
Supabase Compute ist kein neues Betriebssystem, sondern eine Verlagerung. Ein Plattformwechsel weniger, ein Log weniger, ein Zugangsdatensatz weniger. Für Agents und Hintergrundjobs, die eng an den Daten hängen, ist das ein sinnvoller Schnitt. Du bekommst eine Linux-Umgebung, in der dein Dockerfile läuft. Die Datenbank ist nicht einen Netzwerksprung entfernt, sondern liegt daneben.
Die Arbeit verschiebt sich an eine andere Stelle. Wenn Dienste jederzeit neu starten und keinen dauerhaften Speicher haben, ist Postgres der einzige Ort, an dem Zustand überlebt. Lange Backfills müssen in wiederaufnehmbaren Schritten laufen. Job-Prozessoren brauchen Idempotenz; ein abgebrochener Lauf darf beim nächsten Start nichts doppelt schreiben. Das ist keine Nebenbedingung, sondern Teil des Entwurfs.
Die Werkstatt steht jetzt neben dem Regal. Die Werkbank wird aber regelmäßig abgeräumt. Alles, was bleiben soll, muss zurück ins Lager. Wer von Anfang an so baut, hat einen kurzen Weg zwischen Rechnung und Daten und weniger Infrastruktur, um die er sich kümmern muss. Wer es nicht tut, merkt die Neustarts. Die private Alpha taugt für Tests und frühe Projekte; Produktionslast gehört nicht dorthin.
Quelle: supabase.com
