dbt-modellen: vertraging kan waarde in Snowflake kosten

Samenvatting

dbt-modellen buiten het kritieke pad kunnen Snowflake-credits besparen door op kleinere warehouses te draaien.

dbt-modellen en het kritieke pad

Tijdens een sessie op dbt Summit 2026 legden Ben Lerner van Espresso AI en Saravana Kumar van Authentic Insurance uit waarom niet elk dbt-model de totale looptijd van een job bepaalt. In een dbt-DAG vormt het kritieke pad de langste keten van afhankelijkheden; modellen daarbuiten hebben speling en vertragen de eindtijd niet automatisch.

Snowflake en Databricks SQL kennen die DAG-structuur niet. De warehouses voeren opdrachten uit zonder te weten welke query’s afhankelijk zijn en welke parallel kunnen draaien. Volgens Lerner kan een team daarom niet-kritieke modellen op een kleiner warehouse uitvoeren. Een volgende t-shirtgrootte verdubbelt ongeveer de rekenkosten, terwijl de snelheid zelden verdubbelt.

Snowflake-credits en warehousegrootte

De aanpak verschuift de aandacht van alleen sneller rekenen naar gericht capaciteit toewijzen. Een query van vijf seconden die niet op het kritieke pad staat, hoeft volgens de sessie niet op een groot warehouse te draaien. Dat geldt zowel voor Snowflake als voor Databricks SQL, die beide met warehousegroottes werken.

De juiste instelling blijft niet constant. Datavolumes en querypatronen veranderen; een join die eerst lineair opschaalde, kan later zwaarder worden. Espresso AI gebruikt reinforcement learning om warehouse-toewijzingen opnieuw te beoordelen op basis van de DAG, data en uitvoeringspatronen. Authentic Insurance gebruikt daarvoor een tussenlaag die dbt-runs automatisch naar een passende warehousegrootte routeert. Het bedrijf werkt met een klein datateam, ondersteunt ongeveer zeventig medewerkers en heeft meer dan honderd partnerprogramma’s.

Concrete takeaway voor dbt-teams

Breng eerst het kritieke pad van je dbt-DAG in kaart en vergelijk dat met de warehousegrootte per model. Verlaag daarna gericht de capaciteit voor korte, niet-afhankelijke modellen, maar controleer de toewijzing opnieuw wanneer datavolume, joins of querypatronen veranderen.