Datadog KI-gestützte Migration senkt Datenbankkosten um 90 %
Die KI-gestützte Migration von Datadog hat Stream Router, den Dienst, der die Metrik-Pipeline des Unternehmens steuert, von FoundationDB auf PostgreSQL umgestellt, ohne den laufenden Verkehr zu stören, schrieb Ingenieur Arnold Wakim in einem Beitrag, über den InfoQ am 10. Juli 2026 berichtete. Die Entwickler setzten Claude und Cursor Methode für Methode gegen fehlschlagende Tests ein. Laut Unternehmen sanken die aufwendigsten Operationen von 45 Minuten auf etwa eine Sekunde und die Datenbankkosten um 90 %, ein Ergebnis, das ebenso auf der Testsuite wie auf den Modellen beruhte.
Warum Stream Router seinen Key-Value-Speicher sprengte
Datadogs Problem war ein Routing-Dienst, der zum Engpass geworden war. Stream Router ist eine interne Steuerungsebene, die Produzenten sagt, wohin sie Metrikdaten schreiben, und Abfragenden, woher sie lesen. Sie wählt für jeden Datenpunkt Kafka-Cluster, Topic und Partitionen auf einer Plattform, die über hundert Billionen Ereignisse pro Tag verarbeitet.
Es begann als Lösung für ein älteres Problem. 2016 wurde das Routing über eine Konfigurationsdatei mit drei Zeilen verwaltet, die auf Tausende von Zeilen anwuchs, von Hand bearbeitet. Stream Router ersetzte sie durch einen gRPC-Dienst, dessen Schreibpfad mit einem Key-Value-Modell auf FoundationDB lief.
Mit dem Wachstum der Routing-Tabelle stießen kritische Operationen an die Grenzen der Transaktionsgröße von FoundationDB. Die anspruchsvollsten dauerten wegen Tausender aufeinanderfolgender Roundtrips bis zu 45 Minuten. Routen, Streams, Sharding-Strategien und Regeln sind von Natur aus relational, daher zog der Code Zehntausende Einträge in die Pod-Prozesse und arbeitete dort wie eine relationale Datenbank im Prozess.
Was Datadog im Datenmodell geändert hat
Die Lösung war ein relationales Schema. Die Entwickler gestalteten das Datenmodell um die Beziehungen zwischen diesen Entitäten neu, sodass Fremdschlüssel in PostgreSQL Regeln durchsetzen konnten, die der Anwendungscode bisher von Hand nachbaute.
Starke Modularität machte den Wechsel möglich: Der neue Stream Router implementierte dieselbe API auf PostgreSQL statt auf FoundationDB, ohne dass anderswo etwas geändert werden musste. Übrig blieb, die gesamte Codebasis vom alten Modell auf das neue umzubauen, und hier holte das Team Claude und Cursor dazu.
Wie Claude und Cursor Methode für Methode arbeiteten
Die Modelle arbeiteten in einer engen Schleife, nicht auf eigene Faust. Ingenieur Arnold Wakim beschrieb es so.
„Sie haben nicht autonom Code erzeugt: Für jede Methode haben wir die alte Implementierung, das neue Schema und einen fehlschlagenden Test bereitgestellt." — Arnold Wakim, Ingenieur bei Datadog
Die Modelle lieferten einen ersten Entwurf, und die Tests entschieden, ob er stimmte. Die Arbeit verlief in drei Phasen: Zuerst beschrieb Claude die Absicht jeder zentralen Funktion; dann schrieben die Entwickler gezielte Prompts, um fehlschlagende Tests zu beheben, mit dem erwarteten Verhalten und dem Kontext aus dem ersten Schritt; zuletzt ging der neue Dienst in einem Blue/Green-Aufbau in Produktion.
Wie das Team den laufenden Verkehr schützte
Die Sicherheit in der Produktion kam daher, dass beide Systeme gleichzeitig liefen. Zwei unabhängige Instanzen von Stream Router, eine mit PostgreSQL und eine mit FoundationDB, bearbeiteten dieselben Anfragen, während Feature-Flags Clients zwischen ihnen verschoben. Ein Validator-Dienst in jedem Cluster verglich die Routing-Antworten und alarmierte das Team sofort, wenn sie auseinandergingen.
Wo die Modelle an ihre Grenzen stießen
Die Modelle hatten klare Grenzen, die Wakim aufzählt. Prompts auf höherer Ebene funktionierten schlecht. Claude schrieb Abfragen, die korrekte Ergebnisse lieferten, aber weit mehr Roundtrips auslösten als nötig, und Optimierungen wie Batching, UNNEST und Common Table Expressions erforderten menschliche Eingriffe. Hatten die Entwickler das optimierte Muster einmal geschrieben, wiederholten die Modelle es in späteren Methoden, fanden es aber nie selbst. Auch der Token-Verbrauch war hoch, weil das Team die vollständige Testausgabe in die Schleife gab statt gekürzter Auszüge.
Was die Migration gebracht hat
Die gemessenen Ergebnisse stammen vom Unternehmen selbst. Operationen, die 45 Minuten dauerten, sanken auf etwa eine Sekunde, und die Latenzen fielen von Hunderten Millisekunden auf wenige. Der Datenspeicher wurde bis zu 40-mal kleiner, CPU- und Speicherverbrauch sanken, und die Datenbankkosten fielen um 90 %. Datadog sagt, ohne KI-Werkzeuge hätte es die Umsetzung in der verfügbaren Zeit nicht abgeschlossen.
Was das Teams sagt, die eine KI-gestützte Umstrukturierung planen
Für eine Entwicklungsorganisation geht es hier um eine große, repetitive Umstrukturierung von Produktionscode unter Zeitdruck. Die KI-gestützte Migration von Datadog zeigt, wo der Wert liegt: Die Modelle beschleunigten das Tippen, während Testsuite, modularer Aufbau und der parallel laufende Validator die Geschwindigkeit sicher machten. Wakim folgert, dass die Stärke der Testsuite entschied, wie weit das Team KI-generiertem Code vertrauen konnte. Ein Team ohne diese Suite bekäme denselben Code schneller und hätte keine Möglichkeit zu erkennen, ob er stimmt.
Fragen und Antworten
Wie hat Datadog Claude und Cursor bei der Migration eingesetzt?
Für jede Methode gaben die Entwickler den Modellen die alte Implementierung, das neue Schema und einen fehlschlagenden Test. Die Modelle schrieben einen ersten Entwurf, und die Tests zeigten, ob er stimmte.
Welche Ergebnisse brachte die Migration zu PostgreSQL?
Datadog sagt, Operationen sanken von 45 Minuten auf etwa eine Sekunde, Latenzen von Hunderten Millisekunden auf wenige, der Speicher schrumpfte um bis zu 40-mal, und die Datenbankkosten fielen um 90 %.
Was konnten die KI-Modelle nicht?
Sie schrieben korrekte, aber langsame Abfragen. Batching, UNNEST und Common Table Expressions erforderten menschliche Entwickler, und die Modelle nutzten diese Muster erst, nachdem sie sie gesehen hatten.
Die Sicht von MOZGII
Wie wir es bauen würden
Die Lehre aus diesem Fall ist, dass das Modell der unauffälligste Teil war. Datadog konnte Maschinencode vertrauen, weil es für jede Methode einen Test gab, eine Schnittstelle, die sich nicht änderte, und zwei laufende Systeme, die nebeneinander dieselben Anfragen beantworteten. Um diese drei Dinge würden wir jede große Umstrukturierung aufbauen, bevor wir ein Modell wählen.
In der Praxis würden wir zuerst die fehlschlagenden Tests schreiben, einen pro Methode, und sie als Spezifikation behandeln. Das Modell bekäme für jede Aufgabe ein kleines, festes Paket: den alten Code, das neue Schema und den Test. Ein Entwickler würde jede Änderung prüfen, die besteht, und die langsamen Pfade verantworten, etwa Datenbankabfragen, bei denen eine korrekte Antwort trotzdem viele zusätzliche Roundtrips kosten kann. Die Testausgabe würden wir kürzen, bevor sie zum Modell geht, denn vollständige Logs trieben hier den Token-Verbrauch.
Brechen würde es dort, wo Tests dünn sind. Eine Methode mit schwacher Abdeckung lässt falschen Code fertig aussehend durch, und ein paralleler Validator fängt nur das, was der Live-Verkehr zufällig auslöst. Die eine Kennzahl, die wir beobachten würden, ist, wie oft der Validator einen Unterschied zwischen altem und neuem System findet, nach Routentyp, bis sie lange genug bei null bleibt, um das alte abzuschalten.
Als Nächstes würden wir die von Hand geschriebenen Abfragemuster in einer gemeinsamen Bibliothek ablegen, die das Modell zuerst liest, damit die nächste Migration dort beginnt, wo diese endete.
Quellen
Woher die Fakten dieser Meldung stammen.
- 01How Datadog Used Claude and Cursor for Test-Driven Production Migration - InfoQinfoq.com
- 02How we migrated a live routing system using AI-assisted refactoring | Datadogsecurity-platformrumcidashboardhost-mapapmsecurity-platformrumcidashboardhost-mapapmsecurity-platformrumcidashboardsecuritydatadoghq.com