Jobs vs All-Purpose Compute: Cost Difference
Post · Presets matter · List rates 2026-09-24 · Estimates only
On list pricing, All-Purpose (interactive) compute is priced at a much higher $/DBU than Jobs Compute, so scheduled ETL on All-Purpose clusters is usually the expensive habit you should break first. Same nodes and hours are not the same bill when the SKU changes.
Use Jobs (or appropriate job workflows) for recurring pipelines; keep All-Purpose for exploration, then auto-stop it. This post shows the arithmetic with this site’s illustrative rates — not a promise of percentage savings on your contract.
What the presets mean
In /tools/cost/ the workload preset switches the illustrative $/DBU pulled from rates.json (updated 2026-09-24):
- Jobs ETL — ~$0.15 / DBU list (education)
- All-Purpose — ~$0.55 / DBU list (education)
- SQL Warehouse — ~$0.22 / DBU list (education)
Those are list figures for teaching. Your cloud, region, Photon flags, and enterprise discount will differ. The structural lesson remains: interactive SKUs cost more per DBU than job SKUs on published list cards.
Side-by-side estimate (same shape)
Hold constant: AWS, 4 medium nodes, 160 hours/month, 1.5 DBUs per node-hour, idle 0, VM band $0.50/node-hour.
Jobs preset
- DBUs = 4 × 160 × 1.5 = 960
- DBU $ ≈ 960 × 0.15 = ~$144
- VM $ ≈ 640 × 0.50 = ~$320
- Total rough ≈ ~$464
All-Purpose preset
- Same 960 DBUs
- DBU $ ≈ 960 × 0.55 = ~$528
- VM $ still ≈ ~$320 (classic VMs)
- Total rough ≈ ~$848
DBU line alone nearly quadruples on this illustrative list pair; total TCO rises sharply even though VM is unchanged. We will not convert that into a marketed “save X%” claim — your mix, discounts, and idle behavior dominate real outcomes. The actionable point is directional: do not park ETL on All-Purpose.
When not to use All-Purpose
- Nightly / hourly ETL and ELT that can run as Workflows Jobs
- dbt or Spark jobs that need no interactive notebook attached
- “Always-on” shared clusters used as a poor man’s scheduler
- Long-running streams that have a Jobs or dedicated streaming pattern available in your platform standards
All-Purpose earns its keep for data science exploration, debugging, and ad-hoc analysis. The failure mode is leaving it up overnight (see idle clusters) or using it as the default compute for every task because “it was already there.”
Practical migration pattern
- Inventory notebooks that write production tables on a personal All-Purpose cluster
- Wrap the code in a Job (multitask workflow if needed)
- Size a Jobs cluster similarly; measure duration once
- Re-estimate with the Jobs preset in the calculator
- Set All-Purpose auto-stop to a short timeout for remaining interactive work
Practice on retail_orders.csv: one notebook prototype, then the same SQL/Python as a scheduled job — follow the TCO walkthrough.
SQL Warehouse note
SQL Warehouse sits in between on our illustrative list card and serves BI-style query patterns. Do not assume it replaces Jobs ETL or All-Purpose notebooks; pick the product that matches the workload, then cost it with the matching preset. Still add infrastructure reality per product docs (classic vs serverless packaging).
Governance tips (no fluff)
- Tag clusters with
workload=jobs|interactive|sqlfor showback - Alert on All-Purpose clusters older than N hours
- Require Jobs compute policies for production writers
- Document list vs contract $/DBU in the same FinOps sheet
Every report should say estimate, show DBU $ and VM $, and cite the rates date.
Takeaway
Presets are not cosmetic: Jobs vs All-Purpose changes $/DBU on list pricing and therefore the DBU leg of TCO. Keep interactive clusters for interactive work; put pipelines on Jobs; verify with both columns in the calculator.