Supabase kauft Turso, weil Agenten eine Datenbank pro Aufgabe brauchen

Supabase gab am 2. Oktober bekannt, dass das Unternehmen 150 Millionen US-Dollar eingesammelt hat und Turso übernimmt, ein Datenbankunternehmen auf SQLite-Basis. Die Runde wurde von Singapurs GIC angeführt, mit Beteiligung von Alphabet-Wachstumsfonds CapitalG, IronArc und SquarePeg. Der Übernahmepreis wurde nicht genannt, und die Finanzierungsankündigung sollte nicht als Kaufpreis verstanden werden.

Die architektonische Wette hinter dem Deal ist der interessante Teil. Supabase hat sein Geschäft um Postgres herum aufgebaut, ein relationales System, das für Anwendungen entwickelt wurde, die einen gemeinsamen, konsistenten Datenspeicher nutzen. Turso hat SQLite von Grund auf neu geschrieben und die Single-Writer-Beschränkung entfernt und es dann über eine plattenlose Architektur bereitgestellt, bei der das Write-Ahead-Log auf S3 liegt. Das Ergebnis ist eine Datenbank, die sich bei Bedarf pro Agent bereitstellen lässt – zu einem Bruchteil der Kosten, die das Hochfahren einer Maschine für jeden einzelnen Agenten verursachen würde.

Die Zahlen, die Supabase nennt

Supabase gibt an, inzwischen monatlich mehr als eine Million Nutzer und rund vier Millionen Datenbanken hinzuzugewinnen. Das Unternehmen berichtet, dass etwa 70 Prozent der neuen Datenbanken auf der Plattform von Agenten oder KI-gesteuerten Tools erstellt werden. Im Juni meldete es einen Anstieg der Datenbankanzahl um 600 Prozent im Jahresvergleich und erklärte, Agenten seien bereits für die meisten neuen Deployments verantwortlich. Das Unternehmen sagt, dass mehr als 13 Millionen Entwickler die Plattform nutzen.

Das sind vom Unternehmen gemeldete Adoptionszahlen, und die Anzahl erstellter Datenbanken ist nicht dasselbe wie Umsatz oder Retention. Eine Datenbank, die ein Agent für eine Aufgabe hochzieht und eine Stunde später aufgibt, zählt trotzdem in diese Monatssumme. Was die Zahlen jedoch zeigen, ist die Form der Nachfragekurve: Das Volumen der erstellten Datenbanken wächst schneller als die Zahl der Menschen, die sie erstellen – genau das Signal, dass das Modell „eine Datenbank pro Anwendung“ unter Druck gerät.

Warum eine Datenbank pro Agent die alte Rechnung sprengt

Die Einheit der Infrastruktur verändert sich. Wenn ein menschlicher Entwickler eine Anwendung baut, bedient eine Datenbank viele Nutzer, und die Kosten für ihre Bereitstellung werden über ein langlebiges Projekt amortisiert. Wenn ein Agent eine Aufgabe ausführt, braucht er möglicherweise einen eigenen Scratch-Speicher für Zustand, Gedächtnis oder Zwischenergebnisse – und das vielleicht nur für ein paar Minuten.

Eine Instanz pro Agent nach herkömmlichem Managed-Database-Modell bereitzustellen, funktioniert in dieser Größenordnung nicht. Der Overhead für die Zuweisung eines Servers, seine Konfiguration und Abrechnung übersteigt den Wert der kleinen Workload, die darin läuft, bei Weitem. Turso verspricht, dass eine Datenbank nahezu nichts kosten sollte, um sie zu erstellen, und nahezu nichts, um sie im Leerlauf zu halten – sodass eine Million davon zu starten ein normaler Vorgang ist und kein Buchhaltungsereignis.

Die Kundenliste, die Supabase für Turso anführt, umfasst Superhuman, CTO.new, Sauna.ai und Mastra. Turso-Gründer Glauber Costa wechselt als Head of Agentic Services zu Supabase, zusammen mit Mitgründer Pekka Enberg und dem restlichen Team.

Ein Detail sollten alle beachten, die Turso bereits nutzen. Der frühere libSQL-Fork des Unternehmens und seine neuere Rust-Engine sind unterschiedliche Implementierungen, und beide haben nicht denselben Funktionsumfang. Turso erklärte den Übergang in einer Ankündigung zum Rewrite im Januar 2025. Ein Team sollte prüfen, auf welcher Engine sein Deployment läuft, bevor es davon ausgeht, dass ein auf der Marketingseite aufgeführtes Feature in der Produktion verfügbar ist.

Die Konkurrenz, auf die das abzielt

Die Übernahme macht auch klarer, mit wem Supabase konkurriert. Sein Bezahlangebot umfasst Authentifizierung, Storage, Edge Functions, Echtzeit-Abonnements und Vektorsuche, was das Unternehmen im Markt für Managed Backends gegen Firebase, MongoDB Atlas und AWS Aurora positioniert statt gegen einen einzelnen Datenbankanbieter.

Jeder davon hat eine andere Schwäche auf der Agenten-Ebene. Firebase bindet Entwickler an ein Dokumentmodell und an Googles Cloud. MongoDB Atlas modelliert Daten flexibel, berechnet aber einen Cluster statt einer Einheit von Agentenarbeit. Aurora ist leistungsstark und teuer im kleinen Maßstab, mit einer Bereitstellung, die nicht zu einer Aufgabe passt, die nur wenige Minuten lebt.

Tursos Beitrag ist die kleinstmögliche Speichereinheit. Es bietet gleichzeitige Schreibvorgänge, native Vektorsuche und Ausführung im Browser, dazu eingebettete Replikation zwischen Geräten und der Cloud. Die letzte Fähigkeit ist wichtig für eine Klasse von Anwendungen, die teilweise auf dem Rechner eines Nutzers läuft, wo ein Roundtrip zu einer Cloud-Datenbank nicht die richtige Form für das Problem ist.

Der Graduation-Pfad ist der kommerzielle Mechanismus. Ein Projekt, das als eine einzelne SQLite-Datenbank beginnt und zu einer echten Anwendung heranwächst, migriert zu Postgres – und damit in einen kostenpflichtigen Plan. Supabases Argument ist, dass es günstiger ist, das Projekt in dem Moment zu gewinnen, in dem ein Agent es erstellt, als den Entwickler später zu akquirieren.

Die Finanzierungshistorie ist ein eigenes Signal

Die Runde kommt vier Monate, nachdem Supabase im Juni 2026 eine Series F über 500 Millionen US-Dollar abgeschlossen hat, die das Unternehmen mit 10,5 Milliarden US-Dollar post-money bewertete und ebenfalls von GIC angeführt wurde. Dieser Runde war im Oktober 2025 eine Series E über 100 Millionen US-Dollar bei einer Bewertung von 5 Milliarden US-Dollar vorausgegangen. Das insgesamt eingeworbene Kapital liegt nun über der Marke von 1 Milliarde US-Dollar.

Eine so bald erneute Finanzierung deutet darauf hin, dass das Unternehmen entweder Kapital oder eine Schlagzeile wollte, und in der Mitteilung heißt es, ein Teil der Runde diene der Liquidität für Mitarbeiter. Eine Sekundärkomponente für Beschäftigte ist in dieser Phase normal, und sie sollte vom operativen Cash getrennt betrachtet werden, das ein Unternehmen tatsächlich einsetzt.

Die strategische Logik ist klarer als die finanzielle. Supabase möchte die erste Anlaufstelle sein, an die sich ein Entwickler oder ein Agent wendet, wenn ein Projekt ein Backend braucht. Wenn die früheste Version dieses Projekts eine winzige, von einem Agenten erstellte SQLite-Datenbank ist, dann bedeutet, den Moment der Erstellung zu besitzen, die Beziehung zu besitzen, bevor ein Wettbewerber das Projekt überhaupt sieht. Von dort aus bietet Supabase einen Graduation-Pfad in Standard-Postgres, wenn eine Anwendung der Leichtgewichtsklasse entwachst. Turso läuft weiter als Plattform, und seine Codebasis bleibt Open Source.

Das Konsolidierungsmuster

Supabase ist mit diesem Schritt nicht allein. Restate hat in diesem Monat eine Series A über 20 Millionen US-Dollar unter der Führung von Singular eingesammelt, für robuste Infrastruktur, die verhindert, dass lang laufende Agenten-Workflows mitten in der Aufgabe fehlschlagen. LlamaIndex hat ein schema-basiertes Werkzeug zur Dokumentenextraktion für Agenten-Datenpipelines veröffentlicht. Das Thema dieser Deals ist, dass die Infrastruktur unter Agenten zu einer Kategorie wird und die Teile davon, die früher ein Nachgedanke waren, nun finanziert werden.

Für Entwickler ist die praktische Frage, was sich ändert. Bestehenden Supabase-Nutzern wird gesagt, dass sie keinen Unterschied bemerken werden, was die richtige Antwort für eine Plattform ist, die nun zwei Engines unter einem Dach betreibt. Die folgenreichere Verschiebung betrifft die Standardeinstellungen. Wenn Postgres und SQLite im selben Ökosystem leben, wird die Wahl zwischen ihnen zu einer Entscheidung über die Form der Workload statt über den Anbieter, und die günstige Option wird in dem Moment verfügbar, in dem ein Agent sie braucht, statt erst nach einem Beschaffungszyklus.

Offen bleibt, ob die Ökonomie trägt. Ein Datenbankmodell pro Agent ist nur tragfähig, wenn die Kosten für Speicher, Bereitstellung und Support unter dem Preis bleiben, den ein Kunde zu zahlen bereit ist, und wenn genügend dieser Datenbanken zu bezahlten Produktions-Workloads heranwachsen. Supabase hat darauf gewettet, dass die Antwort Ja lautet und dass die Projekte, die es wert sind, behalten zu werden, klein anfangen.