Dagster+ pricing runs on credits. Credit consumption is easy to underestimate, particularly for large dbt projects or high-frequency runs, so budgeting requires understanding the model.
The Credit Model
1 credit = 1 asset materialization or 1 op execution.
Every time Dagster materializes an asset — runs a Python function, executes a dbt model, syncs a Fivetran connector — that’s one credit. For dbt projects, each model materialization counts as a separate credit because each model is a separate asset.
This means a dbt project with 100 models running daily uses approximately 3,000 credits per month (100 models x 30 days). The math is straightforward but the implications catch people off guard: adding models, increasing run frequency, or running ad-hoc materializations all consume credits.
Plan Tiers
| Plan | Price | Credits/month | Users | Best for |
|---|---|---|---|---|
| Solo | $10/mo | 7,500 | 1 | Solo practitioners, small dbt projects |
| Starter | $100/mo | 30,000 | Up to 3 | Small teams, moderate dbt projects |
| Pro | Contact Sales | Custom | Custom | Larger teams, enterprise features |
Overage
Beyond your plan’s included credits: $0.03 per credit.
For context: a 100-model dbt project running daily (3,000 credits) fits comfortably in the Solo tier at $10/month with 4,500 credits to spare. But a 200-model project running twice daily (12,000 credits) exceeds Solo and pushes into Starter territory. Add sensors, Python assets, and ad-hoc materializations, and credit consumption grows faster than the dbt model count alone suggests.
Serverless Compute
If you use Dagster’s serverless compute (where Dagster runs your code on their infrastructure rather than yours), there’s an additional cost: $0.005 per compute minute on Solo and Starter. This applies when Dagster executes the actual computation — running dbt, processing Python functions, etc. For workloads that primarily orchestrate external services (telling BigQuery to run a query, triggering a Fivetran sync), the compute minutes are minimal. For heavy Python processing, they add up.
Cost Comparisons
The pricing makes the most sense in comparison to alternatives.
vs. dbt Cloud
| dbt Cloud Starter | Dagster+ Solo | Dagster+ Starter | |
|---|---|---|---|
| Monthly cost | $100/user/month | $10/month | $100/month |
| 3-person team | $300/month | N/A (1 user) | $100/month |
| Includes | dbt scheduling, CI, docs, IDE | Full orchestration, scheduling, sensors, lineage | Same + 3 users, more credits |
| Cross-system orchestration | Not included | Included | Included |
For pure dbt orchestration, Dagster+ is cheaper. The full comparison covers what you lose (dbt Cloud IDE, documentation hosting, semantic layer access) and what you gain (cross-system orchestration, event-driven scheduling, unified UI).
vs. Cloud Composer
Cloud Composer 3 starts at approximately $300-400/month idle. Dagster+ Solo at $10/month is 30-40x cheaper for small workloads. Even Composer’s 3-year committed rate (~$160-215/month) is more expensive than Dagster+ Starter.
The cost gap narrows at scale. Composer’s cost is relatively fixed (you pay for the environment), while Dagster+ scales with usage. A team running thousands of asset materializations daily may find the costs comparable or even inverted.
vs. Open Source Dagster
The free open-source version (Apache 2.0 license) costs nothing for the software itself. Self-hosting requires infrastructure: a PostgreSQL database for run storage, a web server, a daemon process, and compute for execution. On GCP, this means a GKE cluster or a VM, plus Cloud SQL. The infrastructure cost depends on sizing but typically starts at $50-100/month on GCP.
What you lose with open source:
- No RBAC (role-based access control)
- No branch deployments
- No alerts to external services (Slack, PagerDuty)
- No catalog search or Dagster+ Pro features
- No managed infrastructure or support
For solo practitioners and small teams, Dagster+ Solo at $10/month is almost certainly cheaper than self-hosting when you factor in the time cost of managing infrastructure.
Credit Consumption Gotchas
Each dbt model is a credit
A dbt build that runs 100 models consumes 100 credits, not 1. This is because each model is a separate Software-Defined Asset. Teams migrating from dbt Cloud (which prices per user, not per execution) sometimes underestimate this.
Op executions count too
Credits aren’t just asset materializations. Each op execution (the lower-level Dagster primitive that assets are built on) also counts. For most analytics engineering workflows this doesn’t matter — you’re working with assets, not raw ops. But if you build custom pipelines using the @op decorator, those executions add to your credit bill.
Sensors and schedules don’t consume credits
Sensor ticks and schedule evaluations are free. Only actual materializations consume credits. A sensor that checks every 5 minutes whether Fivetran completed doesn’t cost anything until it triggers a materialization.
Ad-hoc materializations count
Manually materializing an asset in the UI (common during debugging or development) consumes a credit. If you’re iterating on a model and materializing it 20 times in a day, that’s 20 credits. For development workflows, consider using dagster dev locally where materializations don’t count against your Dagster+ credits.
Budgeting Heuristic
A reasonable budget estimate:
- Count your dbt models
- Multiply by daily runs (1x for daily, 2x for twice-daily, etc.)
- Multiply by 30 days
- Add 20-30% for sensors, Python assets, ad-hoc runs
Example: 150 models, daily runs = 150 x 1 x 30 = 4,500 base credits + 30% buffer = ~5,850 credits/month. Fits in Solo (7,500 included) at $10/month.
Example: 300 models, twice daily = 300 x 2 x 30 = 18,000 base credits + 30% = ~23,400 credits/month. Fits in Starter (30,000 included) at $100/month.
Monitor usage from the first week. The Dagster+ dashboard shows credit consumption trends.