How to calculate Burn Multiple in SQL
Contents:
Why Burn Multiple is the number every SaaS board now opens with
Burn Multiple is the cash-efficiency metric David Sacks introduced at Craft Ventures in late 2020, and it has quietly become the single number that frames every late-stage SaaS board meeting. The question it answers is brutal: for every dollar your company is burning, how much Net New ARR are you buying? A company adding two dollars of recurring revenue per dollar burned posts a 0.5 and sets its own terms. A company adding fifty cents per dollar burned posts a 2.0 and is now asked to explain its go-to-market motion.
The metric matters because the easy ones lie at scale. ARR growth alone says nothing about how the growth was bought — a 60 percent YoY print funded by 200 million USD of burn looks healthy until you realize it cost three dollars per dollar of ARR added. Burn Multiple captures the entire engine in one ratio: all cash out, all recurring revenue in, normalized to a number that compares cleanly across companies and quarters.
A CFO at a Series C company gets a slack message at 6:47 a.m.: the lead investor wants Burn Multiple by quarter for the last eight quarters before the 10 a.m. call. This post walks through the SQL — the textbook quarterly query, the rolling four-quarter view, the QoQ change with LAG, and a clean summary. Every query runs in Postgres and translates to Snowflake, BigQuery, or Redshift.
The formula and the David Sacks bands
The headline formula is one line.
Burn Multiple = Net Burn / Net New ARRNet Burn is the cash consumed during the period — operating expenses minus operating cash receipts. Net New ARR is the change in the recurring book during the same period, decomposed the same way an ARR waterfall is built.
Net New ARR = New ARR + Expansion ARR - Churn ARR - Contraction ARRA Burn Multiple below 1.0 means the company is generating more than one dollar of new recurring revenue per dollar burned — the territory of the most efficient growth stories. David Sacks publishes the bands as a five-tier table.
< 1.0 Amazing
1.0 - 1.5 Great
1.5 - 2.0 Good
2.0 - 3.0 Suspect
> 3.0 BadThese thresholds are conventions, not laws of physics, but the venture community refers to them often enough to have become the de facto grading scale. Companies above 3.0 are usually in conversations about cuts before a round.
The data model we will use
Two tables are enough. The first is a quarterly P&L roll-up; the second is the subscription-events log used by every ARR query in the warehouse.
pnl_quarterly (quarter, net_burn, operating_expenses,
operating_revenue, one_time_items)
subscription_events (customer_id, event_at, mrr_change, kind)pnl_quarterly.quarter is a date pinned to the first day of the quarter. net_burn is operating expenses minus operating cash receipts, positive when the company spent more than it received. one_time_items carries non-recurring charges like legal settlements or M&A fees that finance keeps visible so analytics can adjust them out. subscription_events.mrr_change is signed — a churn is the customer's full MRR with a minus sign.
Four SQL queries you will actually ship
1. The textbook quarterly Burn Multiple
Pull Net Burn and Net New ARR from their respective sources, divide, and you have the number.
WITH net_new AS (
SELECT
DATE_TRUNC('quarter', event_at)::DATE AS quarter,
SUM(mrr_change) * 12 AS net_new_arr
FROM subscription_events
WHERE event_at >= '2024-01-01'
GROUP BY 1
)
SELECT
p.quarter,
p.net_burn,
COALESCE(n.net_new_arr, 0) AS net_new_arr,
p.net_burn::NUMERIC / NULLIF(n.net_new_arr, 0) AS burn_multiple
FROM pnl_quarterly p
LEFT JOIN net_new n USING (quarter)
WHERE p.quarter >= '2024-01-01'
ORDER BY p.quarter;The NULLIF guard is non-negotiable. Net New ARR can land at zero in a slow quarter, and dividing by zero blows up the query. NULLIF(..., 0) converts that to NULL, which is the right semantic — Burn Multiple is undefined when there is no new ARR to attribute the burn against. The NUMERIC cast prevents Postgres from doing integer division when both columns happen to be integers. If you need the four-way decomposition — new, expansion, churn, contraction — extend the CTE with conditional aggregates on kind.
2. The rolling four-quarter Burn Multiple
A single quarter is noisy. One enterprise deal slipping from Q1 into Q2 swings the ratio in both directions. The version investors quote is the rolling four-quarter — burn and Net New ARR summed over the trailing twelve months.
WITH quarterly AS (
SELECT
DATE_TRUNC('quarter', event_at)::DATE AS quarter,
SUM(mrr_change) * 12 AS net_new_arr
FROM subscription_events
GROUP BY 1
),
combined AS (
SELECT
p.quarter,
p.net_burn,
COALESCE(q.net_new_arr, 0) AS net_new_arr
FROM pnl_quarterly p
LEFT JOIN quarterly q USING (quarter)
)
SELECT
quarter,
SUM(net_burn) OVER w AS trailing_burn,
SUM(net_new_arr) OVER w AS trailing_net_new_arr,
SUM(net_burn)::NUMERIC OVER w
/ NULLIF(SUM(net_new_arr) OVER w, 0)
AS trailing_burn_multiple
FROM combined
WINDOW w AS (ORDER BY quarter ROWS BETWEEN 3 PRECEDING AND CURRENT ROW)
ORDER BY quarter;The ROWS BETWEEN 3 PRECEDING AND CURRENT ROW frame is the standard four-quarter trailing window. The first three rows are warm-up and should be filtered. The named WINDOW clause is Postgres-native and Snowflake-compatible; on BigQuery, inline the window definition.
3. Quarter-over-quarter change with LAG
The directional read — is efficiency improving or deteriorating — usually matters more than the level. LAG puts the previous quarter's value next to the current one, and the delta tells the story.
WITH base AS (
SELECT
p.quarter,
p.net_burn::NUMERIC
/ NULLIF(SUM(e.mrr_change) * 12, 0) AS burn_multiple
FROM pnl_quarterly p
LEFT JOIN subscription_events e
ON DATE_TRUNC('quarter', e.event_at)::DATE = p.quarter
GROUP BY p.quarter, p.net_burn
)
SELECT
quarter,
burn_multiple,
LAG(burn_multiple) OVER (ORDER BY quarter) AS prev_quarter,
burn_multiple
- LAG(burn_multiple) OVER (ORDER BY quarter) AS qoq_change,
CASE
WHEN burn_multiple < 1.0 THEN 'Amazing'
WHEN burn_multiple < 1.5 THEN 'Great'
WHEN burn_multiple < 2.0 THEN 'Good'
WHEN burn_multiple < 3.0 THEN 'Suspect'
ELSE 'Bad'
END AS sacks_band
FROM base
ORDER BY quarter;The CASE block attaches the David Sacks band directly to the row. This is the version that goes into the investor update — a quarter, a Burn Multiple, a directional delta, and a label that frames the conversation. If you have not used LAG and LEAD recently, the SQL window functions interview questions post drills exactly this pattern.
4. The clean reporting view
The final query bundles the headline, the trailing twelve-month version, the QoQ delta, and the band into one row per quarter — the shape an analyst at Stripe or Notion hands a CFO without further editing.
WITH quarterly_arr AS (
SELECT
DATE_TRUNC('quarter', event_at)::DATE AS quarter,
SUM(mrr_change) * 12 AS net_new_arr
FROM subscription_events
GROUP BY 1
),
joined AS (
SELECT
p.quarter,
p.net_burn,
COALESCE(q.net_new_arr, 0) AS net_new_arr,
p.net_burn::NUMERIC
/ NULLIF(q.net_new_arr, 0) AS burn_multiple
FROM pnl_quarterly p
LEFT JOIN quarterly_arr q USING (quarter)
)
SELECT
quarter,
net_burn,
net_new_arr,
ROUND(burn_multiple, 2) AS burn_multiple,
ROUND(
SUM(net_burn) OVER w::NUMERIC
/ NULLIF(SUM(net_new_arr) OVER w, 0), 2
) AS ttm_burn_multiple,
ROUND(
burn_multiple
- LAG(burn_multiple) OVER (ORDER BY quarter), 2
) AS qoq_change,
CASE
WHEN burn_multiple < 1.0 THEN 'Amazing'
WHEN burn_multiple < 1.5 THEN 'Great'
WHEN burn_multiple < 2.0 THEN 'Good'
WHEN burn_multiple < 3.0 THEN 'Suspect'
ELSE 'Bad'
END AS sacks_band
FROM joined
WINDOW w AS (ORDER BY quarter ROWS BETWEEN 3 PRECEDING AND CURRENT ROW)
ORDER BY quarter;ROUND(x, 2) keeps columns readable — Burn Multiple is conventionally reported to two decimal places. If the dashboard supports a sparkline column, the trailing-twelve-month series alongside the headline quarter is what a board member wants at a glance.
Common pitfalls
The first trap is confusing Net Burn with Gross Burn. Gross Burn is total operating expenses — every dollar that left the company. Net Burn nets operating revenue against those expenses, which is the right number for efficiency analysis. Using Gross Burn overstates Burn Multiple, often by a factor of two for a company with meaningful recurring revenue. Confirm with finance which line you are pulling.
The second trap is using gross new ARR instead of Net New ARR. A quarter with 5 million USD of new business and 4.5 million USD of churn nets out at 500,000 USD of recurring growth. Dividing burn by gross new ARR gives a flattering Burn Multiple that disappears the moment an investor asks for the waterfall. Always put Net New ARR — new plus expansion minus churn minus contraction — in the denominator.
The third trap is mismatched timing. Sales and marketing spend in Q4 closes deals in Q1, but burn lands when cash leaves and ARR lands when the contract signs. A naive same-period join punishes Q4 for spending that paid off one quarter later. The honest version smooths over a trailing four-quarter window, which is why the rolling twelve-month Burn Multiple is the version investors quote.
The fourth trap is treating one-time items as recurring burn. A 4 million USD legal settlement in Q2 makes Q2 look catastrophic even if the operating engine was healthy. Carry an adjusted Burn Multiple alongside the gross version, and footnote any line more than five percent of quarterly burn.
The fifth trap is publishing a Burn Multiple when Net New ARR is negative or zero. The ratio either flips sign or becomes undefined, and neither means what the reader thinks. When the denominator is at or near zero, the right output is a sentence describing the underlying dynamics. A blended CAC breakdown earns its keep here, isolating whether the problem is acquisition cost or churn.
Optimization tips
The queries themselves are cheap because they aggregate at the quarterly grain — eight to sixteen rows. The bottleneck is subscription_events, which grows with every upgrade, downgrade, and reactivation.
The first lever is partitioning subscription_events by event_at on monthly boundaries. Every query above is bounded by a date range, and partition pruning collapses a hundred-month scan into the last twelve. On Snowflake, cluster on event_at. On BigQuery, partition plus cluster on customer_id. On Redshift, sort on event_at.
The second lever is materializing the quarterly ARR aggregate. The CTE SUM(mrr_change) * 12 GROUP BY DATE_TRUNC('quarter', event_at) feeds the Burn Multiple dashboard, the ARR Growth dashboard, the ARR snapshot, and sales-comp dashboards. Materializing it nightly into arr_quarterly removes redundant scans across the reporting stack.
Related reading
- How to calculate ARR in SQL — the snapshot that anchors the denominator of every efficiency ratio.
- How to calculate ARR Growth in SQL — the period-over-period view of the same Net New ARR that feeds Burn Multiple.
- How to calculate Blended CAC in SQL — the unit-economics counterpart diagnosing what drives the burn side.
- SQL window functions interview questions — the trailing-window and
LAGpatterns from the queries above.
If you want to drill SQL questions like this every day, NAILDD is launching with hundreds of analytics SQL problems built around this pattern — efficiency ratios, cohort metrics, and the window-function machinery that powers them.
FAQ
What Burn Multiple is healthy for a growth-stage SaaS company?
The David Sacks scale puts anything under 1.5 in healthy territory, 1.5 to 2.0 as acceptable, and above 3.0 as a flag. Stage matters too. A seed-stage company can post under 1.0 trivially because absolute numbers are small. A Series C at scale is doing well at 1.5 and excellent at 1.0. The metric is most useful as a trend quarter over quarter, and as a peer benchmark against companies at similar revenue scale.
How does Burn Multiple relate to Magic Number?
Both measure efficiency but capture different inputs. Magic Number is sales-driven: annualized new ARR divided by sales and marketing spend, isolating how productively go-to-market converts spend into revenue. Burn Multiple is whole-company: total Net Burn divided by Net New ARR. A company can have a strong Magic Number and a weak Burn Multiple if engineering and G&A are bloated relative to the recurring book. Investors look at both because they answer adjacent questions about where efficiency lives.
Should I report Burn Multiple quarterly or annually?
Quarterly is the standard David Sacks proposed and captures direction quickly enough to be actionable. Annual is too lagging — by the time a full-year number tells you efficiency is deteriorating, you are looking at four quarters of accumulated damage. Market convention publishes the headline quarter and the trailing four-quarter version side by side, so a reader sees both the spot read and the smoothed trend.
What do I do when Burn Multiple is above 3.0?
Four levers. First, the burn side: review operating expenses by category, cut anything not tied to revenue or critical engineering, freeze unjustified hires. Second, the ARR side: review sales conversion at every funnel stage, audit under-priced cohorts, discipline discounting. Third, churn — reducing churn is mechanically identical to adding gross new ARR but cheaper. Fourth, the go-to-market motion itself — if the unit economics do not work in the current channel, no amount of optimization recovers them.
Is Burn Multiple meaningful for profitable or public companies?
Less so. The metric assumes the company is consuming cash to fund growth and loses diagnostic power once Net Burn turns negative. For public SaaS past profitability, the relevant metrics shift to Rule of 40, free cash flow margin, and operating margin. Burn Multiple remains the right number for private growth-stage SaaS — Series B through pre-IPO — where cash efficiency is the central question every funding conversation orbits.