The Slim CI That Got FatWarehouse · medium · ~12 minSix months ago your team adopted Slim CI for the dbt monorepo: PRs build only state:modified models into an ephemeral schema, deferring unchanged refs to production. It started at ~10 minutes per PR. Everyone loved it.This month, CI is the team's top complaint: runs regularly hit the 20-minute timeout and get cancelled more often than they succeed. Developers have started merging with [skip ci] "just for small changes." Meanwhile the Snowflake bill line for the CI warehouse has tripled.Nothing about the CI config changed. The project grew — models, data, contributors. You're diagnosing before someone either doubles the timeout or doubles the warehouse.Evidence

CI trend (6 months)

A slow CI run, profiled

Current setup

Checkpoints

The developer's local run takes 90 seconds; the same models in CI take 20+ minutes. Where does the asymmetry come from?

The profile shows 96% of CI runtime scanning deferred prod tables. If a slim-production replica (7-day filtered) replaced those deferred refs, roughly what CI duration would you predict for this run? (Current: 21 minutes; answer in minutes.)

Why do late-day PRs rebuild "way more models than I changed"?

Write the fix as a design: the slim-production system (jobs, schedules, deferral chain), the bootstrap problem you'll hit on day one, and the honest coverage tradeoff you're accepting — plus why proposals (a) and (b) would have failed.