You’re running a growing startup that’s relied on cron for all your batch ETL work so far. Every job’s dependencies live in your scripts, and you invoke them on fixed schedules. Now that you need more reliability and visibility, you’re weighing Dagster versus Airflow. Both can handle jobs at varying intervals, build dependency graphs, and retry failed tasks. You’ve heard Airflow can be memory-hungry, but you’re not certain it’ll actually strain your infrastructure more than Dagster. Airflow gives you a mature UI, a large ecosystem of operators and community plugins, and battle-tested stability at scale. Its scheduler and webserver can spike RAM usage, especially when you have hundreds of DAGs defined. You’ll also need a metadata database (often Postgres) and a message broker (if you run the Celery executor). Installing and configuring all those components adds operational overhead. Dagster takes a code-first approach. You define pipelines in Python, and its type system and asset catalog help you reason about data flows. The UI is lighter out of the box. You get built-in lineage tracking and testing hooks for each step. It’s newer, so community support and third-party plugins aren’t as extensive as Airflow’s—but it integrates smoothly with modern data tooling (dbt, Spark, Snowflake). Resource use tends to be lower, especially if you run tasks on Kubernetes or spin up workers on demand. If you need a proven, widely supported platform and don’t mind extra infrastructure, Airflow remains the industry standard. If you want faster setup, clear code-based pipelines, and less background bloat, Dagster is worth a closer look. You’ll make trade-offs around ecosystem size versus developer ergonomics and operational simplicity.