Windmill vs dbt

One dbt project is one Windmill script: the project files ride with it as its module bundle, and the worker materializes them into the job directory before invoking dbt. dbt_project.yml is what marks the bundle as a project. Nothing is cloned at run time, and the version of the project is the version of the script, so a deploy is atomic and a rollback is a redeploy.

Three engines, chosen per project: dbt-core-1x (the default, a uv virtualenv resolved per adapter), dbt-core-2x and fusion. None is baked into the image: each is fetched on first use and cached on the worker, and an operator can pre-stage one in a derived image for an air-gapped instance.

Warehouses are configured once per workspace (a name, a resource and an optional target), and a project reaches one by name. The adapter is inferred from the resource type, and Windmill renders profiles.yml before dbt runs. A project that would rather keep its own profiles.yml can, with credentials injected as Windmill variables.

One dbt build per job, with dbt providing the parallelism and Windmill the observability: the project graph turns green model by model while the run is in flight, every node ends with its status, timing, row count and dbt message, test severity is honored, and Preview rows dispatches a dbt show for one node. A failed run resumes from its failure point.

Copy the project into a <script>__dbt/ folder and push it. There is no transformation step and no Windmill-specific file to add. A team whose repository must stay canonical keeps it and lets Git sync push the project in; a team without one pushes from a working copy.

A dbt script opens in an editor shaped like a project: a file tree, the descriptor, the run form and a model graph. Refresh models redraws that graph from the buffer by running a real dbt parse on your workers, so it agrees with dbt about enabled, macro-built refs and package models. The browser is not where a dbt project is developed, though: that stays a local dbt run loop.

Optional, in wm_dbt.yaml inside the project: the engine, the warehouse, select / exclude (dbt's own grammar, passed verbatim), vars, threads, full_refresh, in-job retry of failed nodes, and an env map that resolves Windmill variables for the project env_var() lookups. A {{ }} placeholder in vars becomes a required run argument, so a date-parameterized project gets a real run form, webhook payload and schedule argument.

packages.yml is resolved once, at deploy, and pinned in the script lockfile alongside the engine and adapter versions. A run restores the package tree from a worker-local cache keyed on that resolution, and a worker that resolves anything else is refused rather than run.

Everything is files: the script, the project bundle, resources, schedules and permissions, deployed by CLI or Git sync (free up to 2 users, Enterprise only beyond). Workspace forks give each branch its own environment.

Native. The project runs on a schedule, from a trigger (HTTP, Kafka, Postgres CDC, SQS, MQTT, NATS), from a flow step, the CLI or the API. Concurrency limits keep a project that must not run twice at once from doing so, retries included.

Every model, seed, snapshot and source becomes an asset named dbt://<warehouse>/<schema>/<name>, with dbt's own ref() lineage as edges, taken from the manifest rather than from a scan. Two projects pointing at the same warehouse share their nodes instead of drawing two islands.

A Python, TypeScript, DuckDB or Ansible script that names a dbt:// relation is detected as a reader of that exact node, so the script that ships the mart to a customer appears beside the model that writes it. Column-level lineage is not available for dbt models, since the manifest carries no column-to-column edges; native pipelines do infer it from the SQL.

A dbt run does not fire the scripts downstream of it. dbt already orders its own DAG, and a run select can build any subset, so Windmill refuses to draw a cascade arrow that would not reliably fire; you schedule the consumer or run it from the graph. Native pipelines do cascade: a write triggers every reader.

A copy and a push. The project is not rewritten, not converted and not annotated, and the only Windmill file is a descriptor you can skip. The bundle carries the authored files and leaves out what dbt generates (target, dbt_packages, logs) as well as .env files, whose contents belong in variables instead.

wmill sync pull writes the project back verbatim, and the tree stays a canonical dbt project that dbt itself runs with --project-dir. What you leave behind is the scheduling and the graph, not the models. Adopting the native pipeline runtime instead of dbt is the one path that is a real rewrite, so it mostly makes sense for new projects.

Real-time streaming logs, per-run inputs, outputs and duration, the project graph with per-model status, timing and row counts, and a Prometheus exporter. Every job is a Windmill job, so dbt runs sit in the same run history, alerting and metrics as everything else in the workspace.

SOC 2 Type II. RBAC, SSO (up to 10 users), encrypted secrets and sandboxed execution in open source. Uncapped SSO, extended audit-log retention, SCIM and SAML are Enterprise only. A warehouse is reached by any user allowed to run the script that names it, so warehouse access is granted through the script permissions.

Multiple isolated workspaces on one instance, each with its own users, resources, warehouses and secrets. The free tier is capped at 3 workspaces; unlimited is Enterprise only. Any number of dbt projects per workspace.

Runs land on your own workers, on the dbt worker tag, so a project reaching a private warehouse runs on a worker that can reach it and a heavy project can be pinned to a bigger pool. Engines and package trees are cached per worker, so the cold start is paid once. The warehouse still does the SQL, at whatever threads you set.

AGPLv3 core, free and unlimited to self-host, and the dbt runtime is part of it: only the mssql and oracle adapters need a license. Other Enterprise features (uncapped SSO, dedicated workers, audit logs, external secret backends) ship in a separate proprietary codebase. Managed cloud available.

Public per-seat and per-worker pricing on the pricing page: developers around $20/month, operators $10/month, standard workers $50/month. Nothing is metered per model build, and the open-source core is free however many models you build.