Espresso AI: dbt-Modelle abseits des kritischen Pfads können auf kleineren Snowflake-Warehouses laufen
Die meisten Modelle in einem dbt-DAG haben keinen Einfluss darauf, wie lange ein Job läuft. Wer sie auf kleineren Warehouses ausführt, kann Kosten senken, argumentierte Espresso-AI-CEO Ben Lerner auf dem dbt Summit 2026. Der Kunde Authentic Insurance gibt an, durch das Routing seiner dbt-Läufe über Espresso jedes Quartal 40 % zu sparen.
- Espresso-AI-CEO Ben Lerner sagte auf dem dbt Summit 2026, die meisten Modelle in einem dbt-DAG lägen nicht auf dem kritischen Pfad.
- Jede Warehouse-Größenstufe nach oben verdoppelt in etwa die Rechenkosten, verdoppelt aber selten die Geschwindigkeit. Modelle abseits des kritischen Pfads können daher auf kleineren Warehouses laufen.
- Espresso AI nutzt Reinforcement Learning, um Warehouses laufend neu zuzuweisen, wenn sich DAGs, Daten und Abfragemuster ändern.
- Authentic-Insurance-CTO Saravana Kumar sagte: "Wir sparen jedes Quartal 40 %, weil wir Espresso zwischen unseren dbt-Modellen und Snowflake betreiben."
Der kritische Pfad und der Spielraum drumherum
Jeder dbt-DAG hat einen kritischen Pfad. In der Session wurde er als die längste ununterbrochene Kette von Abhängigkeiten vom ersten bis zum letzten Modell beschrieben. Modelle außerhalb dieser Kette haben Spielraum (Slack): Sie dürfen länger brauchen, ohne den Job zu verzögern. Laut der Zusammenfassung der Breakout-Session von dbt Labs lautete Lerners zentrale Aussage, Teams sollten diesen Spielraum als Ressource nutzen, statt ihn zu ignorieren.
Das Warehouse selbst hilft dabei nicht. Wenn dbt einen Job an Snowflake oder Databricks schickt, kennt das Warehouse den DAG nicht. Es führt aus, was ihm aufgetragen wird, eine Abfrage nach der anderen, und weiß nicht, dass manche Abfragen voneinander unabhängig sind und parallel laufen könnten.
"Das meiste in Ihrem DAG liegt nicht auf dem kritischen Pfad", sagte Lerner. "Es verlängert die Gesamtlaufzeit Ihres Jobs nicht. Und wir können diese Information nutzen, um Geld zu sparen, denn langsamer zu laufen kann günstiger sein."
Die Warehouse-Größe als Stellschraube
Der Hebel ist die Warehouse-Größe. Warehouses von Snowflake und Databricks SQL gibt es in T-Shirt-Größen, und jede Stufe nach oben verdoppelt in etwa die Rechenkosten, verdoppelt aber selten die Geschwindigkeit. Der Artikel verbindet dieses Muster mit dem Amdahlschen Gesetz.
Lerners Empfehlung: den kritischen Pfad ermitteln und alles, was nicht darauf liegt, konsequent verkleinern. Eine kurze Abfrage, die in fünf Sekunden fertig ist, fällt für die Gesamtlaufzeit des Jobs kaum ins Gewicht. Es gibt daher wenig Grund, sie auf etwas Größerem als dem kleinsten verfügbaren Warehouse auszuführen.
Die Schwierigkeit liegt darin, dass sich das Bild ständig ändert. Wächst das Datenvolumen, skaliert ein Join, der früher linear skalierte, womöglich nicht mehr so, und ein Modell, das im letzten Quartal noch sicher abseits des kritischen Pfads lag, kann in diesem Quartal darauf liegen. Der Ansatz von Espresso AI setzt laut der Session statt manueller Abstimmung auf Reinforcement Learning. Er bewertet die Warehouse-Zuordnung laufend neu, wenn sich DAG, Daten und Abfragemuster eines Projekts verändern.
Die Kundensicht von Authentic Insurance
Saravana Kumar, CTO von Authentic Insurance, bestritt die zweite Hälfte der Session. Authentic betreibt die Vertriebsschicht für Spezialversicherungsprogramme in den Bereichen Gastgewerbe, Energie, Binnentransport (Inland Marine) und Bau. Mehr als 100 Partnerprogramme sind live, und für 2025 meldete das Unternehmen ein 15-faches Umsatzwachstum.
Das Unternehmen hat ein kleines Datenteam, das eine Belegschaft von etwa 70 Personen unterstützt. dbt sorgt für eine konsistente semantische Schicht zwischen einer OLTP-Schicht auf DynamoDB und einer OLAP-Schicht auf Snowflake. Espresso sitzt dazwischen, beobachtet die Modellläufe von dbt und leitet sie automatisch an das passend dimensionierte Warehouse weiter.
Die Versicherungsbranche bringt eigene Komplikationen mit. Schäden werden noch Monate nach der ersten Erfassung neu reserviert. Daten, die beim Laden korrekt waren, können später falsch werden, und nachgelagert lässt sich nichts bedenkenlos als reines Anhängen (append-only) behandeln. Jedes neue Partnerprogramm ist faktisch eine neue Datenquelle, die mitten im Projekt hinzukommt. Weil das Geschäft reguliert und für die Versicherer einsehbar ist, ist ein Datenqualitätsproblem zugleich ein Problem für den Kunden.
"Wir sparen jedes Quartal 40 %, weil wir Espresso zwischen unseren dbt-Modellen und Snowflake betreiben", sagte Kumar.
Was das für dbt-Teams bedeutet
Das Argument der Session lautet, dass die Warehouse-Ausgaben in dbt-Projekten nicht nur eine Frage der Abfrageoptimierung sind, sondern davon abhängen, die Rechengröße an die Position jedes Modells im DAG anzupassen. Für kleine Teams liege der Reiz in Einsparungen, ohne dass jemand eine einzige Warehouse-Größe von Hand abstimmen muss.
Die 40 % sind die Aussage eines einzelnen Kunden, wiedergegeben von dessen CTO, und die Quelle nennt keine weiteren Details dazu, wie sie gemessen wurden. Dennoch gibt die Session Teams einen konkreten Ausgangspunkt: den kritischen Pfad ihrer Jobs identifizieren und hinterfragen, ob jedes andere Modell die Warehouse-Größe braucht, auf der es derzeit läuft.
