Loading today’s stories
Build1 distinct publisher3 min readPublished
Airflow's cron string names a time and nothing else, while an Asset URI names data that two DAGs have to agree on. The dependency shape decides which of those contracts you actually want.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Look at what the scheduler is matching on in each case. `schedule="0 13 * * 0"` is five fields of wall clock, and not one of them names a table [4][14]. Airflow will attempt the run at 1 PM on Sunday whether or not the upstream data moved [5]. Data readiness is therefore not in the contract at all; it is an assumption held somewhere outside the DAG file.
The Asset path moves that assumption into code. The producing task carries `outlets=[trusted_customers]`, where `trusted_customers = Asset("postgres://warehouse/trusted/customers")` [8]. The consumer declares the same Asset and passes it as its schedule: `schedule=[trusted_customers]` [9]. The consumer stops guessing when the upstream finishes and reacts to the update event instead, as the post puts it [12].
Now run the original problem through both. The change was described as a one-line edit: rename the source table, deploy, move on [2]. Under cron that is close to true, because the schedule field never mentioned the table. Under Asset triggering the same rename lands on the outlet declaration, and the outlet is the string the consumer subscribes to. In the two snippets as published, the URI literal is written out twice, once per file, with no shared constant imported between them [13]. So the trigger edge is maintained in two places, and the second place is in a different DAG owned by someone who was not in your review [16].
That is the real discriminator, and it is not about which feature is more modern. If the upstream lands on a clock you control and the downstream commitment is stated in clock time, cron encodes the contract you have. If the upstream finishes whenever it finishes and the downstream commitment is "after trusted.customers is current", the Asset edge is the honest encoding, and you are buying that honesty with a cross-DAG string you now have to govern. The post's own list of what hides behind a simple table swap includes scheduling rules, resource consumption, concurrency and lineage [3], and the choice of trigger decides which of those you inherit.
The lineage part is worth crediting, because it is a byproduct rather than a second system. Airflow's documentation, quoted in the post, says the tracking works by means of the inlets and outlets of the tasks [10], with inlets being what a task consumes and outlets what it produces or updates [7]. Declare the edge for scheduling and you get the graph that supports audit trails, governance and debugging without a separate catalog to keep in sync [11]. Assets have been available since Airflow 2.4, when they were called Datasets, and were renamed to Asset in 3.0 [6].
One caveat on provenance: the excerpt breaks off mid-sentence, just as the author starts on whether Assets being more data-aware makes them the default [15]. The verdict above is mine, from chains where producer completion time varies by hours and the downstream owner is a different team. In that context the string-matched edge is worth the coordination cost, mostly because the alternative failure is a stale table nobody notices. If your producer finishes at the same minute every week, cron is not laziness, it is a smaller surface. Both examples set `catchup=False`, which is the one thing the two designs agree on [4][9].
Ranked by verification strength, evidence, and original report placement.
A dev.to post titled "Airflow Scheduling: Assets vs. Cron | Which One Should You Use?" works through an Apache Airflow project and asks whether a DAG should be scheduled with a cron expression or triggered based on an Asset, answering that it depends and that understanding why matters more than knowing how to configure either.
The cron example is DAG(dag_id="my_pipeline", schedule="0 13 * * 0", catchup=False), which the post says runs every Sunday at 1 PM.
With a time-based schedule, Airflow will try to run the DAG at the configured time regardless of whether the data it depends on has actually changed, which the post says is not necessarily a bad thing.
The motivating case is replacing the source table feeding a refined or trusted table, which at first looks like a one-line change: update the table name, deploy the code, and move on.
The post lists what usually sits behind such a change in a real data platform: dependencies, scheduling rules, upstream and downstream processes, resource consumption, concurrency, data lineage, and assumptions that were not obvious when the pipeline was created.
Assets were introduced in Airflow 2.4 under the name Datasets, and in Airflow 3.0 the concept was renamed from Dataset to Asset.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 29, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
launchd Tells You Nothing When a Job Dies, So Your Revenue Reports It Instead1 distinct publisher
build
The release-notes bot that treats its own rate limit as a spec, not an outage1 distinct publisher
build
The transcript is not a database: why agent pipelines die around week three1 distinct publisher
build
Green is four claims wearing one badge, and nobody instruments the fourth1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Checkable code, one voice
Two kinds of claim here can be checked against Airflow itself: that Datasets arrived in 2.4 and became Assets in 3.0, and that a producing task declares outlets while a downstream DAG passes the same Asset to schedule. What cannot be checked is the platform behind the story — no table sizes, no run counts, no named environment — and the text we hold stops mid-example, so the most consequential passage is missing its conclusion.
Nothing deployed to measure
Nobody shipped anything in this story. It is a design question worked through in prose: the two-hour job and the thrice-daily raw table are hypotheticals, the project is unnamed, and there are no before-and-after run counts, costs or rollout details. Scoring uptake from it would mean inventing it.
Undersells its own finding
If anything the piece is too modest. It refuses the "Assets everywhere" answer and lands on "it depends", yet the sharpest thing in it is left for the reader to notice: once a consumer subscribes to postgres://warehouse/trusted/customers, that URI is a contract copied into two files, and the table rename that started the whole inquiry now edits the producer's outlet plus every DAG naming it. The snippets demonstrate this; the prose never says it out loud.
No product at the end of it
Nothing is being sold. Airflow is the subject, no managed vendor or paid tier appears, and the piece ends on an unresolved example rather than a call to action. What remains is the ordinary reputational pull of a practitioner writing up work on a community platform — "I recently had to look into exactly this kind of situation" — which shapes tone and tidiness more than it shapes the facts, since the facts are snippets and a version number.
Verifiable in parts, truncated
Middling, for two plain reasons: a single voice with no second account, and a text that gives out mid-sentence in the middle of its most operationally interesting scenario. The code-level and release-history details are solid enough to act on; the engineering judgement around them is one person's experience on one unnamed platform, and the frequency-versus-cost argument is cut off before it resolves.