Dataset identity decides whether you get a graph or a pile of dots. In OpenLineage a Dataset is a namespace plus a name, a Run is one execution of a Job with its own run ID, and a Job is either the DAG or one of its tasks [7]. None of those objects holds an edge. Edges are inferred: the backend takes events fired on state transitions, START, RUNNING, COMPLETE, FAIL, ABORT and OTHER [9], and reconstructs lineage by joining datasets across runs [10]. Two tasks are linked only because they spelled a dataset the same way. The walkthrough names inconsistent dataset identity as the most common cause of a first integration that produces nodes and no edges [10], and the console transport will not catch it. Console writes the events into the task log and costs nothing to run [13], and well-formed events with disagreeing names look exactly like working ones.
You can read the shape of the resulting graph out of the demo before running it. It is one task, a `SQLExecuteQueryOperator` on a daily schedule using the `postgres_default` connection to create a table in the `analytics` schema [19]. Because the DAG is a job and each task is also a job [7], that single-task DAG registers two jobs in the backend, and a 40-task DAG registers 41 [22].
The extraction is only as wide as the parser. SQL operators need no code from you because the provider parses the query and derives inputs, outputs and column-level relationships [18]. That is the good engineering here: the lineage is derived from the one artefact that cannot misremember, the query that actually ran. It also sets the boundary. The demo is a CREATE TABLE through a SQL operator [19]; nothing in the walkthrough says what a task with no query to parse emits. So the claim that this replaces manual documentation and the lineage spreadsheet that goes stale in three weeks [21] transfers in proportion to how much of your writing goes through operators the provider can read. Three weeks is generous. If a large share of your loads are Python functions calling an SDK, facets are the extension point, since schema, SQL text, column-level lineage and your own fields all travel as facets attached to the standard objects [8].
The adoption cost is small and mostly one-time: Docker to run a backend locally [20], Python somewhere between 3.9 and 3.12 [3], one `pip install` plus a check that your image does not already ship the provider, which official Airflow Docker images may [11]. The HTTP transport wants a url and the endpoint `api/v1/lineage`, with `disabled = False` in the `[openlineage]` block [15]. After that, the number I would watch in my own context is coverage: the share of task runs emitting at least one input and one output dataset. The config lines are an afternoon. That ratio is what tells you whether anyone should trust the graph.
