Google Cloud macht Datenbanken agentischer – und Cloud Run dauerhafter

Google Cloud reagiert auf zwei typische Infrastrukturprobleme rund um KI-Agenten: Zum einen ist die Auswahl und der laufende Betrieb einer Datenbank aufwendig. Zum anderen lassen sich Agenten, die dauerhaft erreichbar sein und im Hintergrund arbeiten sollen, nur schwer in ein klassisches, anfragebasiertes Serverless-Modell einpassen.

Dafür hat Google im August 2026 zwei neue Bausteine vorgestellt: die Database Operations Agents, die in Gemini Cloud Assist integriert sind, und die Preview von Cloud Run Instances – einer einzelnen, langlebigen Laufzeitumgebung für zustandsbehaftete Workloads. Zusammen zeigen die Produkte, dass Google Cloud sowohl die Daten- als auch die Compute-Ebene stärker auf agentische Anwendungen ausrichtet. 2411

Zwei Datenbank-Agenten für den gesamten Lebenszyklus

Die beiden Agenten sind Teil von Googles Strategie Agentic Data Cloud. Ihre Aufgaben sind klar getrennt: Der Onboarding Agent kümmert sich um die Einrichtung – Googles „Day 0“. Der Observability Agent übernimmt den Betrieb ab „Day 1“ und „Day 2“, also Überwachung, Diagnose und laufende Wartung. 2

Database Onboarding Agent: von Anforderungen zur Bereitstellung

Der Database Onboarding Agent wertet die Anforderungen eines Workloads aus, empfiehlt eine geeignete verwaltete Datenbank und führt durch Konfiguration und Bereitstellung. Damit soll er Architektur- und Provisionierungsentscheidungen vereinfachen, die Teams bisher oft manuell treffen mussten.

Unterstützt werden AlloyDB, Bigtable, Cloud SQL und Spanner. 2 Das ist besonders dort hilfreich, wo ein Entwickler- oder Plattformteam zwar weiß, welche Eigenschaften eine Anwendung benötigt – etwa hinsichtlich Workload und Betrieb –, aber noch nicht sicher ist, welcher Google-Cloud-Dienst am besten dazu passt.

Database Observability Agent: Überwachung und Fehleranalyse

Nach der Bereitstellung übernimmt der Database Observability Agent den laufenden Betrieb. Google nennt unter anderem Flottenüberwachung, Anomalieerkennung, Diagnose, Fehlerbehebung, Optimierung und Wartung. Unterstützt werden Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore und Memorystore. 224

Der Agent betrachtet nicht nur einzelne Messwerte. Er verknüpft Informationen aus Database Insights und der Database-Center-Telemetrie, Cloud Monitoring, Cloud Logging und Cloud Trace. Dazu können Metriken, Abfrageinformationen, Bestandsdaten und Hinweise zu Problemen gehören. Auf dieser Grundlage soll er mögliche Ursachen eines Fehlers ermitteln, statt lediglich eine weitere Dashboard-Warnung auszugeben. 2

Die Funktionen gehen laut Google über Empfehlungen hinaus: Der Agent kann ein Problem erklären, eine Reaktion vorschlagen und mehrstufige Maßnahmen zur Behebung unterstützen. Als Beispiele nennt Google das Aktivieren von Connection Pooling in Cloud SQL oder das Hinzufügen von Indizes. Bei potenziell folgenreichen Änderungen bleibt jedoch ein Mensch im Kontrollprozess: Eine geprüfte Korrektur darf erst nach Freigabe ausgeführt werden. Untersuchungs- und Remediationsfunktionen waren für ausgewählte Kunden als Preview verfügbar. 224

Zugriff über Gemini, Konsole und Entwicklerwerkzeuge

Die Datenbank-Agenten sind in Gemini Cloud Assist integriert. Nutzer können sie über den Gemini-Chat und über die passenden Datenbankseiten in der Cloud Console aufrufen. Google beschreibt außerdem Zugänge über Kommandozeilenwerkzeuge, MCP-Server und -Tools, Drittanbieterwerkzeuge sowie integrierte Entwicklungsumgebungen (IDEs). 2

Damit bleibt die Unterstützung nicht auf ein einzelnes Operations-Dashboard beschränkt. Entwickler und Administratoren können in den Umgebungen arbeiten, die sie ohnehin für Infrastrukturuntersuchungen, Bereitstellungen oder die tägliche Entwicklung nutzen.

Cloud Run Instances sollen KI-Agenten dauerhaft verfügbar machen

Am 28. August stellte Google Cloud außerdem Cloud Run Instances als Preview vor. Dabei handelt es sich um einen anderen Baustein als einen herkömmlichen, automatisch skalierenden Cloud-Run-Service.

Jede Instance läuft als Singleton – es wird also genau eine Instanz betrieben, ohne automatische Skalierung. Google zielt damit auf langlebige, zustandsbehaftete Workloads wie persönliche KI-Agenten. 4

Die wichtigsten Eigenschaften:

• bis zu sieben Tage kontinuierliche Laufzeit,
• eine standardmäßig konfigurierte Richtlinie für automatische Neustarts,
• eine stabile HTTPS-Adresse, die bei Updates und Neustarts unverändert bleibt,
• die Möglichkeit, eine Instance anzuhalten und später fortzusetzen,
• eine einzelne dedizierte Laufzeit statt einer Flotte, die sich an der Zahl eingehender Anfragen orientiert. 4

Dieses Modell passt zu einem Agenten, der für eine Person einen dauerhaften Zustand, eine Identität oder Hintergrundaktivitäten vorhalten soll. Für einen klassischen zustandslosen Web-Endpunkt, der vor allem kurzfristige Verkehrsspitzen abfangen muss, ist ein normaler autoskalierender Cloud-Run-Service naheliegender.

Was Cloud Run Instances laut Google kosten sollen

Google nennt für 30 Tage Dauerbetrieb einer Konfiguration mit 1 vCPU und 1 GiB RAM einen Preis von 5,70 US-Dollar. Dabei kommen eine gemeinsam genutzte vCPU und Burst-Budgets zum Einsatz. 4

Der Vorteil gegenüber dem Betrieb einer eigenen virtuellen Maschine soll nicht nur finanzieller Natur sein. Nutzer müssen sich laut Google unter anderem nicht selbst um die Wartung von VM und Betriebssystem, Firewall-Regeln oder einen eigenen HTTPS-Endpunkt kümmern. Der genannte Preis ist jedoch als veröffentlichte Preview-Angabe von Google zu verstehen, nicht als allgemeiner Kostenvergleich: Die tatsächlichen Kosten hängen von Konfiguration, Nutzung, Region und Abrechnungsdetails ab. 43031

Google verweist außerdem auf eine Aussage des Kunden OffDeal, der von 88 Prozent weniger Kaltstarts berichtet. Dabei handelt es sich um ein Kundenergebnis und weder um eine allgemeine Leistungsgarantie von Google noch um einen unabhängigen Benchmark. 4

Warum die Neuerungen zum KI-Agenten-Trend passen

Klassische Cloud-Anwendungen trennen meist zwischen zustandsloser Anfrageverarbeitung und persistenten Datendiensten. KI-Agenten verwischen diese Grenze. Sie benötigen häufig eine dauerhafte Identität und Adresse, Speicher oder Sitzungszustand, langfristige Hintergrundausführung sowie Zugriff auf Werkzeuge und Betriebsdaten.

Googles August-Neuerungen greifen diese Anforderungen aus zwei Richtungen auf:

1. Die Datenbankebene wird autonomer. Der Onboarding Agent hilft bei Auswahl und Bereitstellung. Der Observability Agent überwacht die Datenbanklandschaft, untersucht Störungen und kann nach Freigabe geprüfte Korrekturen umsetzen. 2
2. Die Compute-Ebene erhält eine auf Persistenz ausgelegte Option. Cloud Run Instances bieten eine stabile, einzelne Laufzeit für Agenten, die verfügbar bleiben sollen, statt bei ausbleibenden Anfragen auf null zu skalieren oder erst beim nächsten Aufruf zu starten. 4

Die übergeordnete Richtung zeigt sich in Googles Konzept der Agentic Data Cloud, das Daten, Modelle und operative Datenbanken zu einem System für agentengesteuerte Aktionen verbinden soll. 11 Bemerkenswert ist dabei die Balance: Google automatisiert mehr Abläufe, behält bei Änderungen mit möglichen Auswirkungen auf Produktionsdaten aber die menschliche Zustimmung als Kontrollpunkt bei. 2

Das Wichtigste für die Praxis

Google Cloud stellt mit diesen Ankündigungen keine universelle „Agentenplattform“ vor. Stattdessen adressiert das Unternehmen zwei konkrete Engpässe:

• Die Database Operations Agents sind interessant, wenn Datenbankauswahl, Bereitstellung, Flottenübersicht oder Fehlersuche den Betrieb ausbremsen.
• Cloud Run Instances kommen infrage, wenn ein Agent eine einzelne, persistente und adressierbare Laufzeit benötigt und nicht zum Scale-to-zero-Modell eines typischen Serverless-Dienstes passt.

Beide Angebote werden in Preview-orientierten Begriffen beschrieben. Teams sollten deshalb vor einem Produktionseinsatz Verfügbarkeit, unterstützte Konfigurationen, Berechtigungen, Preise und die Grenzen automatisierter Korrekturen prüfen. Die strategische Stoßrichtung ist dennoch deutlich: Google Cloud behandelt KI-Agenten zunehmend als Workloads, die sowohl autonomere Betriebsabläufe als auch langlebigere Infrastruktur benötigen.