This guide explains the mechanics of window framing, explicitly detailing how to use the UNBOUNDED PRECEDING boundary to generate accurate running totals.

The Mechanics of Window Framing

When you use a window function like SUM() with an ORDER BY clause, SQL applies a default window frame to the calculation. A window frame defines exactly which rows to include relative to the current row.

To calculate a true running total from the beginning of a dataset up to the current row, the frame must span from the first row to the current row. SQL expresses this boundary concept as UNBOUNDED PRECEDING.

Example 1: The Implicit Running Total

If you include an ORDER BY inside the OVER() clause without explicitly defining the frame, standard SQL automatically applies a default frame: RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW.

Consider a table tracking daily sales:

SELECT 
    sale_date,
    daily_revenue,
    SUM(daily_revenue) OVER (
        ORDER BY sale_date
    ) as cumulative_revenue
FROM daily_sales;

This query successfully calculates the running total. However, relying on the implicit RANGE default introduces a specific edge case involving duplicate sort values.

Example 2: The Explicit ROWS Clause (Best Practice)

The implicit RANGE behavior groups rows with identical sorting values (peers) together. If two sales occur on the exact same sale_date, the RANGE default calculates their combined total and applies that combined sum to both rows simultaneously.

To guarantee strict row-by-row addition regardless of duplicate sort keys, explicitly define the frame using ROWS instead of RANGE.

SELECT 
    sale_date,
    transaction_id,
    daily_revenue,
    SUM(daily_revenue) OVER (
        ORDER BY sale_date, transaction_id
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) as exact_cumulative_revenue
FROM daily_sales;

💡 Developer Tip: Always use explicit ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW for cumulative sums. It forces the database engine to process the sum strictly row-by-row, eliminating unexpected grouping artifacts caused by duplicate order keys. Furthermore, ROWS calculations generally require less memory overhead than RANGE calculations.

Example 3: Partitioning the Cumulative Sum

Data engineering often requires running totals that reset at specific boundaries, such as calculating a monthly running total rather than an all-time running total.

You achieve this by adding a PARTITION BY clause before the ORDER BY. The UNBOUNDED PRECEDING frame then applies only within the boundaries of that specific partition.

SELECT 
    customer_id,
    EXTRACT(MONTH FROM sale_date) as sale_month,
    sale_date,
    daily_revenue,
    SUM(daily_revenue) OVER (
        PARTITION BY customer_id, EXTRACT(MONTH FROM sale_date)
        ORDER BY sale_date
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) as monthly_running_total
FROM daily_sales;

In this query, the cumulative sum begins at the first transaction of the month for a specific customer. When the month or the customer changes, the UNBOUNDED PRECEDING boundary resets, restarting the sum from zero.

Summary

Window functions provide the most efficient mechanism for calculating cumulative sums in relational databases. By explicitly defining the window frame as ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, you ensure precise, deterministic running totals that avoid the logical artifacts of default RANGE behaviors.