When to self-run dbt and when the dbt platform fits
Self-run dbt wins when your data must stay inside your own infrastructure, you already run Airflow or Dagster well, and your team can operate the scheduling, CI and documentation work the platform would otherwise handle for you. The dbt platform fits when you need built-in scheduling and collaboration, you have a small team, and you have few people to spare for platform operations. Both paths run the same SQL models, so the decision rests on who operates the scheduler, the CI pipeline and the docs site, and who pays for that work. Self-run dbt is the stronger choice when data residency rules keep transformation jobs and warehouse credentials inside your accounts, and when an existing orchestrator investment means dbt runs should appear as tasks next to the rest of your pipelines. In that setup, the cost is mostly staff time for the CI jobs, the scheduling, the artifact storage and the upgrade path, all of which recur. Check whether your orchestrator version is supported before you commit: Airflow 2 reached end of life on April 22, 2026, so a team on that line has an upgrade to plan first. Confirm which dbt version and binary you will pin, since the v1 and v2.0 lines are distributed differently.
The dbt platform is the stronger choice when a small analytics team needs scheduled runs, shared job history and a managed docs experience without standing up an orchestrator. Its published Developer plan is free with one developer seat, 3,000 successful model builds a month and one project. The Starter plan is listed at $100 per user per month with five seats and 15,000 builds a month, per dbt Labs' pricing page. Enterprise and Enterprise+ are custom-priced, so ask for a written quote that states seats, build volume, metrics queries and project count. Compare those limits against your expected monthly build count before you pick a tier, because build volume is the metric that most often forces an upgrade. Before you choose, run a short internal audit: count the people who would own CI, scheduling and documentation after go-live, and confirm that your warehouse access model can be expressed as service credentials your orchestrator can hold. If that audit shows one or two engineers with the time to own a scheduler, self-run dbt stays viable. If it does not, the platform's recurring fee is often the cheaper way to buy operational stability, and you can revisit the decision when your build volume or team size changes.
How self-hosted dbt and the dbt platform compare on each factor
This table sets self-run dbt against the dbt platform on license, install form, platform support, where scheduling and CI run, documentation, published plan limits and upgrade ownership. Read each row with the source named in the cell, and confirm any platform feature the public pricing page does not list before you commit to a plan.
| Factor | Self-run dbt | dbt platform |
|---|---|---|
| License and distribution | The dbt-labs/dbt-core source is Apache 2.0. The dbt distribution carries dbt-specific customizations under a dbt product license, so check which one your install uses (dbt README). | Hosted service under dbt Labs' terms. Confirm the contract terms and data handling with dbt Labs (dbt pricing page). |
| Install form | v2.0 ships as a single self-contained binary with no Python runtime. The v1 line remains a Python implementation on the 1.latest branch (dbt README). | Managed by dbt Labs, so you do not install or pin a dbt binary yourself. Confirm which engine versions the platform runs. |
| Platform support | v2.0 runs on macOS and Linux (x86-64 and ARM) and Windows on x86-64. Windows on ARM is not yet supported (dbt README). | Hosted in the browser. Your client machines need only a browser, but confirm supported warehouse adapters with dbt Labs. |
| Scheduling and CI | You build this yourself, typically with an orchestrator such as Airflow or Dagster, plus your CI system. Airflow 2 reached end of life on April 22, 2026 (Airflow supported versions page). | Scheduling and CI runs are included in the platform. Confirm which triggers, environments and CI integrations your plan includes (dbt pricing page). |
| Documentation hosting | You publish generated docs and artifacts such as manifest.json to your own hosting. v2.0 also writes Parquet artifacts (dbt README). | Hosted documentation is part of the platform. Confirm access controls and retention for your environment with dbt Labs. |
| Published plan limits and prices | Free software with no seat or build cap, but you pay for compute, orchestration and storage. | Developer: free, one seat, 3,000 successful model builds a month, one project. Starter: $100 per user per month, five seats, 15,000 builds a month. Enterprise and Enterprise+: custom pricing, 100,000 builds and 20,000 queried metrics a month (dbt pricing page). |
| Who owns upgrades | Your team plans and tests each dbt release, and you own the migration from v1 to v2.0 (dbt-labs/dbt-core releases). | dbt Labs operates the platform. Confirm the upgrade schedule and maintenance notices in your agreement. |
What control and data location change for compliance
Self-running dbt keeps code, credentials, run history and access decisions inside your own boundary, while the dbt platform moves some of those functions to a vendor-hosted service. Each card below is a point where a residency, access or evidence review will ask a specific question, and where the answer depends on your deployment and your contract.
Where code, credentials and artifacts live
In a self-run setup, your repository, warehouse credentials and generated artifacts such as manifest.json sit in your CI runners, orchestrator workers and storage. The dbt platform keeps project configuration and run metadata in dbt Labs' hosted service, so the question is which of those objects leave your boundary. Map every artifact your team writes, then confirm with dbt Labs where platform-side metadata is stored and how warehouse credentials are held.
Who can run and approve models
With self-run dbt, approval is whatever your pull request review and deployment gates enforce, and anyone with orchestrator access can trigger a run unless you restrict it. The dbt platform adds its own user seats and project roles, and the Starter plan lists five seats. Write down who may merge, who may trigger production runs and who may change warehouse targets, then test that the platform or your pipeline enforces the same rules.
How run history and logs are retained
A self-run Airflow deployment keeps task logs and run records wherever you configure them, and their retention is a setting you own. Airflow's production guide recommends PostgreSQL or MySQL as the metadata database, because the default SQLite backend risks data loss. Confirm the retention period for run metadata, task logs and dbt artifacts in both options, since audit requests often ask for evidence from a specific date range.
How access to the orchestrator is governed
Airflow ships an auth manager interface, so access control is defined by the auth manager you configure, and the Airflow documentation covers how it works. Dagster lists role-based access control and SAML SSO as Dagster+ features rather than part of the free open-source Dagster. Decide which access model you need, confirm whether it is free or paid for your version, and document the mapping from identity groups to orchestrator roles.
Hosting and data residency review
The dbt platform is a hosted service, so your residency review must establish where job runs execute, where metadata is stored and whether any warehouse data passes through vendor systems. Self-run dbt keeps execution inside the infrastructure you already assess. Ask dbt Labs for hosting regions, subprocessors, data processing terms and the certifications it holds, and verify each claim against its current documentation before it goes into your evidence pack.
What your team runs in each model
This table compares the operating work each model leaves with your team, separating one-time setup from recurring upkeep. Read it as a list of owners: in a self-run setup your engineers hold every row, while the dbt platform moves some of them to the vendor. The main takeaway is that the recurring items, not the initial install, usually decide the total effort.
| Operating item | Self-run dbt with an orchestrator | dbt platform (hosted) |
|---|---|---|
| Orchestrator install and upgrades | One-time install of Airflow 3.3.2 (current), then recurring upgrades; Airflow 2 reached end of life on April 22, 2026, so Airflow 2 installs need migration | Not applicable; scheduling runs in the hosted platform, and upgrades are handled by the vendor |
| Metadata database | One-time choice of PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or Innovation releases; SQLite is unsuitable for production and MariaDB is not supported | Not applicable to your team |
| Workers and sizing | Recurring capacity planning for executors (for example Kubernetes 1.30 to 1.35 or Celery); at least 4 GB RAM is recommended for the Airflow host | Compute sizing is set by plan limits such as 3,000 builds a month on Developer (dbt pricing page) |
| Multiple schedulers | Optional recurring tuning; Airflow supports more than one scheduler using database row-level locks, which your team must size and monitor | Not applicable; confirm scheduler availability terms with dbt Labs |
| CI pipelines | One-time build of pull request checks, plus recurring maintenance as dbt and adapter versions change | Built-in CI features exist on paid plans; confirm which tiers include them before you plan around them |
| Documentation hosting | One-time setup to generate and publish dbt docs, plus recurring hosting and access control | Documentation is served by the platform; confirm access and retention terms in your quote |
| dbt version upgrades | Recurring work across the v1 Python line and the v2.0 single-binary line, including adapter and parse-time changes | Vendor-managed upgrade path; confirm which dbt version your plan runs and when it changes |
| On-call ownership | Recurring: your team owns failed runs, metadata database health and scheduler incidents at all hours | Recurring but narrower: your team owns model logic and failed tests, while platform incidents sit with the vendor |
What the dbt platform costs against the people and infrastructure behind a self-run stack
The dbt platform has a published price that scales with seats and usage, while a self-run stack has no license fee but puts its cost into staff time and infrastructure. The fair comparison is the total of both over the period you plan to run, not the sticker price against zero. According to the dbt pricing page, the Developer plan is free with one developer seat, 3,000 successful model builds a month and one project. Starter is listed at $100 per user per month with five seats and 15,000 builds a month. Enterprise and Enterprise+ are custom-priced, each with 100,000 successful model builds and 20,000 queried metrics a month, with 30 projects on Enterprise and unlimited projects on Enterprise+. Build counts are the figure to model first, because a team that grows its model count can cross a tier limit before it adds seats.
A self-run setup pays for four things that recur. The largest is engineering time for maintaining the dbt project, the CI pipeline that runs dbt build on pull requests, the scheduler (Airflow or Dagster) and its upgrades. Next are orchestrator hosting, which covers the metadata database, workers and the web server, followed by warehouse compute for scheduled and CI runs, which often costs more than the orchestrator itself. Finally there is documentation and access control work that the platform would otherwise handle. Staff cost rises with the number of environments, the frequency of dbt and orchestrator upgrades and how many people need run-level visibility. Warehouse cost rises with the length of CI runs and how often you rebuild the whole project instead of only changed models.
When you request a quote from DeployOpen, ask for each cost as its own line: one-time build work (CI, scheduler deployment, documentation and access setup), recurring support or retainer hours, and infrastructure you will pay for directly in your own cloud account. Ask which items are fixed-scope and which depend on your model count or team size. Also ask what happens if you later move to the dbt platform, since that changes which items you still carry. DeployOpen does not publish prices. It quotes from a written scope, so the scope you agree on determines the number you receive. Before comparing quotes with the platform figures above, confirm your current build volume with your warehouse query history and your Airflow or Dagster run counts.
Which plan limits push teams toward self-run or the platform
The Developer plan is free with one developer seat, one project and 3,000 successful model builds a month, according to dbt Labs' pricing page. A solo analyst or engineer working on a single project is most likely to hit the build allowance first, since every scheduled run and every local rebuild that goes through the platform draws on the same monthly count. Seats and projects rarely become the constraint at this size.
- Build headroom: Count how many models run per scheduled job, multiply by how often the job runs, and compare that total with 3,000 before assuming the free tier covers production.
- Single seat: A second person who needs to edit or review work moves the team off this plan, so the seat limit is reached as soon as a collaborator joins.
- Self-run removal: Running dbt Core with your own orchestrator removes the platform build cap, but you pay for the warehouse compute and the scheduler you host.
- Self-run addition: You own CI, scheduling, documentation hosting and credentials, none of which the free tier handles for you.
- Hidden cost: Engineering time to set up the pipeline is a one-time cost, and it recurs whenever dbt or the orchestrator is upgraded.
Before deciding, ask dbt Labs how a build is counted for incremental and failed runs, and measure your own job runs in your warehouse to see what compute they actually consume.
The Starter plan lists $100 per user per month with five seats and 15,000 successful model builds a month, per dbt Labs' pricing page. A small team usually hits the seat limit first once a sixth person needs access, and the build count becomes the constraint as the number of models and scheduled jobs grows. Because the price is per user, the seat count drives the monthly bill directly.
- Seat math: Five seats at $100 per user per month is the entry cost before any overage or enterprise terms, so list every person who needs edit or review access.
- Build growth: Fifteen thousand builds a month is five times the Developer allowance, but a team with frequent CI runs on pull requests can consume it faster than expected.
- What the platform adds: Scheduling, hosted collaboration and managed documentation remove work your team would otherwise build and maintain.
- What self-run adds: You keep the same dbt code but take on the orchestrator, CI workers, artifact storage and access control yourself.
- Ownership: Someone on the team must own the self-run stack after the initial build, including upgrades to dbt and the orchestrator.
Confirm with dbt Labs which features are included at this tier, how overages are billed, and whether the build count covers CI runs, then compare that with the measured compute and staff time your own setup would need.
Enterprise and Enterprise+ are listed at custom pricing, with 100,000 successful model builds and 20,000 queried metrics a month. Enterprise allows 30 projects, while Enterprise+ allows unlimited projects, according to dbt Labs' pricing page. Teams at this level most often hit the project count or need governance across many projects, so the question shifts from raw build allowance to how much platform administration the organization wants to buy.
- Project count: Thirty projects on Enterprise is a hard number to plan around, so count the projects you expect within the contract term before choosing between Enterprise and Enterprise+.
- Custom terms: Pricing, support and security terms are set by the contract, so there is no public figure to compare directly with self-run costs.
- Governance: Central access control, audit and shared operations are the main reasons large teams buy the platform rather than run their own control plane.
- Self-run at scale: Self-running many projects means standardizing CI templates, secrets handling, upgrade cadence and documentation across teams, which is a recurring platform engineering cost.
- Compute comparison: Platform build counts cannot be equated with your warehouse compute, so run a representative job load in your own environment before comparing.
Ask dbt Labs for a written quote that states the project count, build and metric allowances, included support and any overage terms, and ask your platform team to estimate the staff time for the self-run alternative.
How to move dbt between self-run and the dbt platform
This sequence gives a team a documented, tested path from a self-run dbt setup to the dbt platform, or back, with each step producing evidence that the new setup builds the same models before the old schedule is retired.
Inventory projects, models, tests and packages
The data engineering lead lists every dbt project, its models, singular and generic tests, macros, seeds, snapshots and package dependencies, including the versions pinned in packages.yml. Record which projects feed production tables and which are experiments. The step is done when the inventory is a shared document that the owners of each project have reviewed, with any custom macros or adapter-specific code flagged for testing on the target. Ask dbt Labs to confirm which project import and migration paths the platform supports before assuming any of them apply to your repository layout.
Pin the dbt version and choose the line
The platform or engineering lead records the dbt version the current project runs and decides whether to stay on the Python v1 line or move to v2.0. The v2.0 distribution is a single binary without a Python runtime, enforces a stricter language specification at parse time and writes Parquet artifacts alongside JSON artifacts such as manifest.json, so each project should be run against the target version in a branch before any decision is made. The sibling comparison on dbt v2.0 and dbt Core v1 covers this choice in depth. The step is complete when the chosen version is pinned in the repository and the parse and compile runs succeed without unexplained warnings.
Map schedules and CI triggers to the target
The platform engineer writes down every job that runs today, including its cron expression, upstream dependencies from the orchestrator such as Airflow or Dagster, pull request checks and any post-run hooks that notify downstream teams. Each trigger is then assigned to a job on the target, whether that is a scheduled run in the dbt platform or a task in the existing orchestrator. The step is done when every job in the inventory has a named counterpart and a documented owner, and nothing runs twice or not at all after the cutover plan is agreed.
Move credentials and environments
The security engineer moves warehouse credentials, service accounts and environment variables to the target using the platform's secret handling or the existing secrets manager, and removes any copies left in orchestrator configuration or CI variables. Development, staging and production targets are reproduced with the same schema names and role grants so that build outputs can be compared. The step is complete when a test build runs under each target identity, the principle of least privilege has been checked against the warehouse role grants, and a record of who holds which credential is stored with the migration documents.
Run both setups in parallel and compare outputs
For a defined period agreed by the team, both the old schedule and the new one build the same models into separate schemas. The analytics engineer compares row counts, column types, test results and key aggregates between the two, and reviews any model that differs in its freshness or lineage. Differences are classed as expected (for example, a version change that alters rounding) or defects to fix. The step is done when the comparison report shows no unexplained differences for the production models in scope and each sign-off owner has accepted the results in writing. The length of the parallel run should be set by the team's own reporting calendar, not by a figure from this page.
Cut over and retire the old schedule
The platform lead switches the production schedule to the target, points downstream consumers at the new schema if the naming changed, and disables the old jobs rather than deleting them immediately. Alerts and on-call routes are updated so that failures notify the team that owns the new setup. The step closes when the first scheduled production runs complete successfully, the disabled jobs are kept for an agreed rollback window, and the retirement is recorded in the change log. Only after that window closes should the old orchestrator tasks, stored credentials and CI configuration be removed.
Document the new operating model
The documentation owner updates the runbook with the new job list, owners, alert routes, release process for dbt upgrades, package update cadence and the steps for rolling back a failed run. The team also records what the target does for scheduling, collaboration and documentation that the old setup did not, and what the team must still maintain itself. The step is complete when a team member who did not perform the migration can follow the runbook to trigger a run, diagnose a failed job and roll back a deployment in a test environment.
What buyers ask before choosing self-run dbt or the dbt platform
What does running dbt yourself actually cost in staff effort?
Running dbt Core yourself has no license fee, but it moves cost into engineering time and infrastructure. The dbt-labs/dbt-core repository is Apache 2.0, so the software itself is free to use. The recurring work sits in four places: the orchestrator that runs your models (Airflow, Dagster or similar), the CI pipeline that tests changes before merge, the scheduling and alerting you build, and the documentation site you publish. The main cost drivers are how many models and environments you run, how many people deploy changes, and how much on-call coverage the pipelines need. Ask any quote to separate one-time setup from ongoing upkeep, and to state which upgrades, such as moving between dbt v1 and dbt v2.0 releases, are included. Compare that against the platform prices on the dbt pricing page.
How long does a self-run dbt setup take to stand up?
No duration is published for this, and the scope sets it. A self-run setup needs a working orchestrator, a warehouse connection, a CI job that builds and tests changed models, a scheduled production run and a way to publish documentation. Each piece depends on your existing tooling, your warehouse and how many projects you migrate. Treat any timeline as a scope question. DeployOpen plans and implements these pieces under a fixed scope agreed in writing before work starts, so the deliverables and timeline are set there rather than assumed in advance. Ask for a written list of deliverables and the acceptance tests for each one.
Can a team run dbt on its own without outside help?
Yes, a capable data team can run dbt Core without a vendor, because the software is open source under Apache 2.0 and no paid edition is required to run it. The harder question is whether the team has time to own the surrounding system. Self-running means someone maintains the orchestrator, keeps CI green, rotates credentials, handles upgrades and answers when a scheduled run fails overnight. Teams that already run Airflow or Dagster in production usually carry less new work. Teams without that experience should weigh the platform's built-in scheduling against the hours they would spend building their own. DeployOpen can supply implementation, hardening and ongoing support as a fixed-scope engagement or retainer, while the team keeps ownership of its data.
What skills does a self-run dbt setup need from the team?
The skills split by layer. dbt models are written in SQL and Jinja, so analytics engineers need strong SQL and a working knowledge of dbt's testing and dependency model. The dbt v2.0 line is a Rust rewrite distributed as a single binary, so teams that stay on the Python v1 line need Python packaging skills, while teams that move need to check the stricter parse-time language rules. Orchestrator administration is separate work: Airflow 3.3.2 expects PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or Innovation releases for its metadata database, and Kubernetes 1.30 to 1.35 if you use that executor. Database operations cover backups, permissions and query performance on the warehouse. Map each skill to a named owner before you commit.
Must Airflow 2 deployments move before anything else?
Airflow 2 reached end of life on April 22, 2026, and after that date it gets no fixes, according to the Airflow version support table. The Airflow support policy also says limited-maintenance versions receive only security and critical bug fixes, and Airflow 2 entered that phase on October 22, 2025. If your dbt schedule runs on Airflow 2, plan the move to Airflow 3 before adding new dbt work, because every new pipeline built on an unsupported version adds to the migration later. Check your DAGs against the upgrade guide, since the hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of Airflow 3.0.0. Confirm the sequence in your own environment with your platform team.
What does the dbt platform add that a self-run setup must build?
The platform bundles scheduling, a hosted environment and collaboration features that a self-run setup has to build or buy separately. The Developer plan is free with one developer seat, 3,000 successful model builds a month and one project. The Starter plan is listed at $100 per user per month with five seats and 15,000 builds a month, according to dbt Labs' pricing page. Enterprise and Enterprise+ are custom-priced, with 100,000 successful model builds and 20,000 queried metrics a month, and 30 projects on Enterprise or unlimited projects on Enterprise+. Compare these limits with your model count, run frequency and seat count, and confirm current limits on the pricing page before you decide.
What should I ask for in a self-run dbt quote?
Ask for a written scope that lists each deliverable, the systems it touches and the acceptance test for each. Request a separate line for one-time setup (orchestrator configuration, CI pipeline, production schedule, documentation publishing, access controls) and for recurring work (upgrades, monitoring, on-call, credential rotation, retainer support). Ask which dbt line is in scope, whether the Airflow version is already supported, and who owns the warehouse and orchestrator credentials after handover. Confirm whether the quote includes knowledge transfer and runbooks. DeployOpen does not publish a price list, and a quote follows from the written scope, so the quality of the scope determines the quality of the estimate.
How DeployOpen scopes, delivers and supports self-run dbt
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, and that includes running dbt Core with an orchestrator such as Airflow or Dagster. Engagements start with a written scope so you can compare the build effort against the dbt platform's published plans before committing.
How we scope
- Written scope lists which dbt projects, warehouses and orchestrator your team will run.
- Scope records how many models, environments and developers the self-run setup must serve.
- Scope names the CI, scheduling and documentation deliverables agreed before work starts.
How we build
- Build covers orchestrator deployment, dbt job scheduling and the CI pipeline for pull requests.
- Build includes database connections, secrets handling and the metadata store the orchestrator needs.
- Testing covers model tests, failure alerting and a rehearsed rerun of a failed scheduled job.
How we hand over
- Handover includes runbooks for scheduling, dependency failures, upgrades and credential rotation.
- Documentation explains how generated dbt docs are published and who maintains them afterward.
- Your team receives the configuration and an agreed walkthrough before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover dbt and orchestrator version upgrades, including support window changes.
- Ask for the support scope, response expectations and upgrade process in the written quote.
