Setup:

CREATE TABLE orders AS SELECT * FROM (VALUES
  (1, 1, DATE '2026-01-01', 10),
  (2, 1, DATE '2026-01-01',  5),
  (3, 1, DATE '2026-01-02', 20),
  (4, 1, DATE '2026-01-12',  7)
) t(order_id, customer_id, order_date, amount);

1. The default frame is RANGE, not ROWS

SELECT order_id, order_date, amount,
       SUM(amount) OVER (ORDER BY order_date) AS default_frame,
       SUM(amount) OVER (ORDER BY order_date, order_id
                         ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS rows_frame
FROM orders ORDER BY order_id;

With an ORDER BY and no frame, the frame is RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW: rows with the same order_date are peers and are all included. Always write the frame.

2. ROW_NUMBER without a tie-breaker is non-deterministic

ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date) must number orders 1 and 2 (same date) in some order, and nothing says which one gets number 1. Reruns can return different rows. Add a unique tie-breaker:

SELECT * FROM orders
QUALIFY ROW_NUMBER() OVER (PARTITION BY customer_id
                           ORDER BY order_date, order_id) = 1;

If ties are meaningful ("top 3 including ties"), use RANK or DENSE_RANK instead.

3. LAST_VALUE returns the current row

SELECT order_id,
       LAST_VALUE(amount) OVER (ORDER BY order_date, order_id) AS looks_wrong,
       LAST_VALUE(amount) OVER (ORDER BY order_date, order_id
            ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS actual_last
FROM orders ORDER BY order_id;

looks_wrong is just each row's own amount (10, 5, 20, 7), because the default frame ends at the current row. actual_last is 7 everywhere.

4. WHERE runs before window functions

"Show the running total, but only display January 2nd onwards":

-- wrong: rows before Jan 2 are removed BEFORE the sum is computed
SELECT order_id,
       SUM(amount) OVER (ORDER BY order_date, order_id
                         ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS running
FROM orders WHERE order_date >= DATE '2026-01-02';      -- 20, 27

-- right: compute first, filter after
SELECT * FROM (
  SELECT order_id, order_date,
         SUM(amount) OVER (ORDER BY order_date, order_id
                           ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS running
  FROM orders
) WHERE order_date >= DATE '2026-01-02';                  -- 35, 42

Logical order: FROM → WHERE → GROUP BY → HAVING → window → QUALIFY → SELECT → ORDER BY.

5. "Last 7 rows" is not "last 7 days"

ROWS BETWEEN 6 PRECEDING AND CURRENT ROW counts rows. On sparse data (no orders between Jan 2 and Jan 12) that window reaches back weeks. Use a time-based frame where your engine supports it:

SELECT order_id, order_date,
       SUM(amount) OVER (ORDER BY order_date
            RANGE BETWEEN INTERVAL 6 DAYS PRECEDING AND CURRENT ROW) AS last_7_days
FROM orders ORDER BY order_id;     -- 15, 15, 35, 7

or build a date spine (one row per day, COALESCE missing days to 0) and then use ROWS. BigQuery, for example, only allows numeric RANGE offsets, so you would order by UNIX_DATE(order_date) there.

6. Bonus: a test fixture that catches a missing PARTITION BY

(Thanks to Emily Woods for suggesting this in the comments.) With a single customer, a missing PARTITION BY customer_id is invisible: every row is in the same partition anyway. Add a second customer with an order on the same date and the wrong query fails visibly:

INSERT INTO orders VALUES (5, 2, DATE '2026-01-01', 100);

SELECT order_id, customer_id,
       SUM(amount) OVER (ORDER BY order_date, order_id
            ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS no_partition,
       SUM(amount) OVER (PARTITION BY customer_id ORDER BY order_date, order_id
            ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS per_customer
FROM orders ORDER BY order_id;

Customer 2's 100 bleeds into customer 1's running total. That's a nice way to turn these snippets into a small regression set: one fixture per trap, each designed so the wrong query visibly fails. (Run this after the other examples; it changes the table.)

The likely follow-up questions in an interview: "How does this scale in Spark?" (a window with ORDER BY sorts each partition; one huge customer causes skew) and "How would you do the 'latest record per key' incrementally?" (deduplicate the batch, then MERGE).

These come from the Data Engineering Interview Kit 2026, which has 80 questions with trade-offs, common mistakes and follow-ups, plus a SQL practice set whose solutions are all executed in DuckDB. Free sample (20 questions): https://payhip.com/b/18A5n

About me: I work as an independent data engineer and DevOps freelancer (IT-Craftsman) and have delivered several data engineering and DevOps projects for large companies. I also work for a technology consulting firm, where I conduct hiring interviews for data engineers and DevOps engineers.

All SQL in this post was executed in DuckDB.

@dag(schedule="0 0 * * *", start_date=pendulum.datetime(2026, 10, 1, tz="UTC"))
def daily_orders():
    @task
    def extract(ds=None):
        load_orders_for(ds)   # which day is ds?
    extract()

Nothing is broken. The default timetable changed. Here is what is going on and how to make your DAGs independent of it.

Airflow 2: a run covers an interval and starts after it ends

In Airflow 2, [scheduler] create_cron_data_intervals defaults to True, so a bare cron string becomes a CronDataIntervalTimetable. Each run covers a data interval and is started after the interval ends:

logical_date (and therefore ds) equals data_interval_start: the day being processed. This confused a generation of engineers ("why does the Oct 1 run start on Oct 2?"), but it made "process yesterday" DAGs work naturally.

Airflow 3: a run is triggered at the cron time

In Airflow 3 the default is create_cron_data_intervals = False, so a bare cron string becomes a CronTriggerTimetable. The run starts at the cron time, logical_date is the trigger time, and data_interval_start and data_interval_end are normally the same moment unless you configure an interval.

So the run that starts at midnight on October 2nd has ds = 2026-10-02 in Airflow 3, but processed 2026-10-01 in Airflow 2. If your task does WHERE order_date = '{{ ds }}', it now loads the current (incomplete) day.

The official upgrade guide calls this out: if you rely on data_interval_start/data_interval_end or on ds/ts, either set create_cron_data_intervals=True before upgrading or pin an explicit timetable. (Another change while you are there: catchup now defaults to False.)

The fix: stop depending on the default

Pin the timetable in the DAG and give it an explicit interval. Then the DAG behaves the same regardless of the global config:

from datetime import timedelta
import pendulum
from airflow.sdk import dag, task
from airflow.timetables.trigger import CronTriggerTimetable

@dag(
    schedule=CronTriggerTimetable("0 0 * * *", timezone="UTC", interval=timedelta(days=1)),
    start_date=pendulum.datetime(2026, 10, 1, tz="UTC"),
    catchup=False,
)
def daily_orders():
    @task
    def extract(data_interval_start=None, data_interval_end=None):
        # run at 2026-10-02 00:00 gets [2026-10-01 00:00, 2026-10-02 00:00)
        load_orders(window_start=data_interval_start, window_end=data_interval_end)
    extract()

daily_orders()

Note: even with interval=, logical_date (and ds) is the trigger time (Oct 2), so template on data_interval_start/data_interval_end, not on ds.

And make the task read the window it is given, never "now":

# bad: depends on when the task happens to run (retries, backfills, catchup all break)
load_orders(window_start=date.today() - timedelta(days=1))

# good: depends only on the run
load_orders(window_start=data_interval_start, window_end=data_interval_end)

A checklist before you upgrade

1. grep your DAGs for ds, ds_nodash, ts, logical_date, execution_date (removed in Airflow 3), data_interval_start.

2. For each DAG with a bare cron string, decide: interval semantics or trigger semantics? Pin it explicitly.

3. Check manual triggers: Airflow 3's upgrade guide warns not to assume a manually triggered run's data_interval equals the logical_date you typed in.

4. Make tasks idempotent (delete-and-replace the run's window, or MERGE by key), so a run that processed the wrong day can simply be rerun.

5. Add a test that imports every DAG and asserts the timetable class you expect.

This is a condensed version of one question from the Data Engineering Interview Kit 2026. Interviewers love it because it tests whether you understand why idempotent, interval-based tasks matter. The free sample with 20 full questions (answers, trade-offs, common mistakes, follow-ups) is here: https://payhip.com/b/18A5n

About me: I work as an independent data engineer and DevOps freelancer (IT-Craftsman) and have delivered several data engineering and DevOps projects for large companies. I also work for a technology consulting firm, where I conduct hiring interviews for data engineers and DevOps engineers.

Facts checked against the Airflow 3 documentation ("Upgrading to Airflow 3", "Timetables").