Cost Optimization and DBU Economics on AWS

Every other lesson in this course builds something; this lesson keeps the invoice honest. A Databricks lakehouse on AWS generates two independent bills: Databricks bills you in DBUs (Databricks Units, the platform license, metered per second) and AWS bills you for the EC2, EBS, S3, NAT and CloudWatch underneath. Forget either meter and your "cost optimization" is fiction: the DBU half can be perfectly tuned while a NAT Gateway quietly adds $0.045 per GB of S3 traffic, and the AWS half can be all-spot while an all-purpose cluster idles at $0.55/DBU all weekend.

The good news is that Databricks cost is arithmetic, not vibes. Every rate in this lesson is date-stamped to October 2026 and traced to a primary or documentary source: the Databricks pricing pages and page-data files (read 2026-10), the UK G-Cloud 15 supplier record for Jobs/All-Purpose list rates (captured 2026-09-25), the Databricks docs for billing tables and auto-stop (updated 2026-09-11 / 2026-10-08), the AWS Price List for EC2/S3 (read 2026-10-12) and the AWS pricing pages for NAT, Spot and CloudWatch (read 2026-10). Do the math yourself; it is the only way to run a lakehouse that is still affordable in year three.

In this lesson you will:

• read the Oct-2026 DBU rate card by compute SKU, jobs, all-purpose, SQL Classic/Pro/Serverless, Lakeflow pipelines, with the provenance of every number spelled out;
• apply the two equations (clusters: nodes × emission × rate × hours; warehouses: size rate × up-time) in five hand-computed worked examples;
• make the serverless-vs-classic break-even decision with arithmetic instead of doctrine;
• configure auto-stop, auto-termination, spot workers, instance pools and cluster policies as cost controls, with the documented defaults and their minimums;
• attribute every dollar with system.billing.usage, budgets and tags, and know exactly which costs never appear there;
• run the worked monthly TCO case for a five-person team (three pipelines, a BI warehouse, S3/NAT/logs) and cut it 34.1% with three levers;
• weigh the Comparative Verdict: DBUs vs Snowflake credits vs Athena's $5/TB scanned;
• study named AWS customer cost stories (Addepar, Nubank, Comcast), read the 2026 update box, and practise with twelve questions plus five interactive checks.

---

1. Two bills, not one: the Databricks cost model on AWS

1.1 What a DBU is

Databricks' own definition: "Databricks bills based on Databricks units (DBUs), which are units of processing capability per hour based on VM instance type" (docs.databricks.com/aws/en/getting-started/concepts, doc date 2026-09-25). The pricing page puts it the other way round: "A Databricks Unit (DBU) is a normalized unit of processing power on the Databricks Lakehouse Platform used for measurement and pricing purposes" and "Only pay for the products you use at per second granularity" (databricks.com/product/pricing, read 2026-10).

Three consequences decide everything that follows:

1. For cluster compute, DBU consumption = (nodes) × (DBU/hr of that node type) × hours: the 2022 cost-management blog states it plainly: "With the exception of a SQL Warehouse, the amount of DBUs consumed is based on the number of nodes and the computational power of the underlying VM instance types" (databricks.com/blog/best-practices-cost-management-databricks, 2022-10-18; the arithmetic still holds at Oct-2026 rates).
2. For SQL warehouses, DBU consumption = (the size's fixed DBU/hr) × hours the warehouse is up: running or not, the meter turns while the warehouse is up (pricing docs, read 2026-10).
3. The meter is per second, and it does not know whether you are working. An idle all-purpose cluster and a crunching one emit DBUs at the same rate. That is why idle time, not query speed, is the core cost-optimization problem on classic compute.

1.2 The two meters

Serverless folds the machine cost into a higher DBU rate. SQL Serverless at $0.70/DBU versus SQL Classic at $0.22/DBU (databricks.com/product/pricing/databricks-sql, page snapshot 2026-10) is a $0.48 per-DBU-hour premium that pays for the fleet, the ops and the idle time you no longer own. Jobs Serverless $0.35 minus Jobs Classic $0.15 is the same picture at $0.20 per DBU-hour. Classic is not free; it just moves half the bill to AWS, where you can attack it with spot and right-sizing.

⚠️ system.billing.usage is not your total bill. Databricks is explicit: "The system.billing.usage only contains Databricks costs. This means that in any instance where non-serverless compute is being used, cloud infrastructure spend is not included and would need to be reviewed via the relevant cloud console (compute, networking, storage, etc.)" (databricks.com/blog/top-5-system-table-queries-understanding-your-databricks-costs, 2026-09-22). A Databricks-only budget under-counts the real number by the entire AWS column.

• 📚 Did you know? Databricks meters DBUs per second (pricing FAQ, read 2026-10), while Snowflake bills credits "per second with a 60-second minimum" (Snowflake warehouse overview + service consumption table, read 2026-10). On short, frequent jobs that 55-second difference is a real line item: one of the quiet reasons bursty workloads favour serverless Databricks jobs over an always-resumed classic fleet.

1.3 The Oct-2026 rate card (AWS, US regions, Premium tier, list)

Read the provenance column before you quote a rate. The SQL and Lakeflow-Pipelines figures come from Databricks' own pricing surfaces (page snapshots and the pricing site's page-data file). The Jobs and All-Purpose figures are documentary and corroborated, the UK G-Cloud 15 public supplier record (a legal filing by Databricks Inc.) plus six independent 2026 reads that all agree, because databricks.com renders those cards client-side. Treat every figure as US list, Premium tier: the pricing FAQ states "Databricks prices and Cloud Infrastructure prices may vary based on geographic region and cloud service provider" (read 2026-10), and in-account truth lives in system.billing.list_prices (your contract's price).

Two rules of thumb with official backing:

• Same pipeline, all-purpose vs jobs = 3.7× the per-DBU rate ($0.55 ÷$0.15 ≈ 3.7): before you count a single idle minute.
• Serverless costs ~1.3×: 2.3× more per DBU than classic for the same SKU family, and removes the EC2 bill, the pool management and the idle time with it.

Region effect: classic rates are flat across AWS regions because you pay the local EC2 price separately; serverless rates track regional infrastructure: SQL Serverless $0.70 in us-east-1 versus $0.91 in eu-central-1 (hejlsvigconsulting.com read of the pricing page data file, 2026-08-07). A US quote never transfers to Frankfurt.

1.4 Worked example E1: the basic equation and a combined bill

The 2022 cost-management blog's own worked pattern, re-priced at today's Premium Jobs rate (blog, 2022-10-18; EC2 price list, us-east-1, read 2026-10-12):

That last line is the number you will reuse all lesson: $0.214 all-in per DBU-hour on classic jobs versus $0.35 for jobs serverless, which is why classic wins on hot, long, predictable shapes and serverless wins on short, bursty or erratic ones (section 3). The caveat the blog itself implies: pair the emission rate of your node type with that node type's EC2 price, and read both from the pricing calculator or system.billing.list_prices, the 3 DBU/hr + m5.xlarge pair above is illustrative, not a matched shape.

---

2. The SKU ladder: your most powerful pricing lever

Before tuning a single query, check that the workload sits on the right SKU. SKU selection is free, instant, and, per Databricks' own field reports, worth more than most performance work.

2.1 The three ladder crimes

1. A pipeline on all-purpose compute. A job pointed at an existing all-purpose cluster is billed at All-Purpose rates and flagged as an interactive workload (Jobs API 2.0; digest 06, read 2026-10). Databricks "does not recommend this configuration for production jobs." The rate difference alone is $0.55 →$0.15 per DBU.
2. The retired Standard tier in your runbook. Jobs at $0.10/DBU was Standard; AWS/GCP Standard workspaces were upgraded to Premium on 2025-10-01 (Azure 2026-10-01) per the pricing page (read 2026-10). Any pre-2025 rate table you copy is stale by 50%.
3. Premium-vs-Enterprise confusion across clouds. AWS/GCP "Premium" is Azure's "Enterprise" card: AWS Jobs is $0.15 Premium / $0.20 Enterprise (a 33% difference) and every serverless SKU moves with it (G-Cloud record 2026-09-25; licenseware 2026-10-06). Always label the cloud and the tier.

2.2 Worked example E2: one pipeline, one month, all-purpose vs jobs

The same 12 DBU/hr pipeline, 400 cluster-hours per month, same 4 × m5.xlarge on the AWS side (rates as of Oct 2026):

One pipeline. One dropdown in the job definition. Databricks' own summary of the estate-wide version: "We've seen customers who have saved tens of thousands of dollars by simply moving just ten percent of their workloads from all-purpose clusters to jobs clusters" (cost-management blog, 2022-10-18: aged source, unchanged arithmetic).

• 📚 Did you know? Materialized-view refreshes are billed as serverless pipeline usage, not warehouse usage, so a 'warehouse' cost tab will not show them (Databricks blog, 2026-10-07). Predictive optimization has been on by default for accounts created on or after 2024-11-11, and it also bills under serverless usage records. If your attribution queries only group by warehouse, these two SKUs are invisible leaks.

---

3. Serverless vs classic: the break-even arithmetic

"Serverless is 4× dearer" is the most expensive sentence in Databricks cost discussions, because it compares DBU rates while ignoring the AWS column on the classic side. The honest comparison is all-in per emitted DBU-hour.

Three practical readings:

• Classic wins when the cluster runs hot and long on a predictable shape: batch ETL windows, big nightly backfills, ML training on a known node count. You are already paying roughly $0.192/h for an m5.xlarge (EC2 price list, read 2026-10-12); classic folds that into a $0.15/DBU license instead of a $0.35/DBU bundle.
• Serverless wins on short, bursty, interactive or unpredictable work, dashboards with gaps between refreshes, ad-hoc notebooks, event-driven jobs, because "you are not charged while it is idle" (Databricks Answers, 2026-08-27) and the fleet, patching and capacity planning disappear.
• The operational constraints matter as much as the price. Serverless jobs have a documented 7-day maximum runtime, no JAR/Spark-Submit tasks, no R/Scala notebooks, no RDD APIs, no instance profiles, and Structured Streaming triggers limited to Trigger.AvailableNow() (recommended); while classic exists precisely where those constraints bind (digest 06, docs read 2026-10). Migrate the pattern (volumes instead of DBFS, DataFrame API instead of RDDs) before you flip the SKU.

---

4. Idle time: auto-stop, auto-termination, and the billed-while-up rule

Databricks' own sentence about warehouses: "Idle SQL warehouses continue to accumulate DBU and cloud instance charges until they are stopped" (docs.databricks.com/aws/en/compute/sql-warehouse/create, last updated 2026-09-11). There is no softer way to say it: a warehouse that is up is a warehouse that is billed. Ten hours left up for forty minutes of dashboards bills ten hours.

4.1 The documented defaults (as of Oct 2026)

Two subtleties. First, the auto-stop defaults differ by a factor of 4.5 between classic/Pro (45 min) and serverless (10 min): if your dashboards refresh every 20 minutes, the classic default guarantees you pay for 25 idle minutes after every session. Second, autotermination_minutes = 0 (disabled) is a legal API value and the single most common source of weekend runaway spend; an enforced policy beats a weekly manual sweep (section 6.3).

4.2 Worked example E4: auto-stop arithmetic on the BI warehouse

From the monthly TCO case in section 9: a serverless SQL warehouse serving BI is up 10 hours a day for 21 working days (210 hours, 2,520 DBU at an assumed 12 DBU/h T-shirt emission). Measured usage shows dashboards actually query in a 6-hour window:

No query was rewritten. No data was moved. The warehouse was simply not left on. (The 12 DBU/h figure is the Small T-shirt emission assumed by this case: meter sizes per warehouse T-shirt are not published as an official table, so read yours from system.billing.list_prices in your account before reusing the arithmetic.)

4.3 Worked example E5: an enforced auto-stop / auto-termination policy

Cluster policies are admin-managed JSON rule sets over Clusters-API attributes whose benefits include "cost control via price-driving attributes" (docs, read 2026-10). The policy reference (read Oct 2026) documents the autotermination_minutes attribute path and a virtual dbus_per_hour range that acts as a hard DBU ceiling; node-type restriction is likewise a policy capability. A minimal cost-guardrail policy for a team workspace:

The mechanics that make this a guardrail rather than a suggestion: one limitation per attribute; API-created compute ignores policy defaults unless apply_policy_default_values: true is set; spark_version: auto:latest-lts resolves only when compute is edited, not continuously; and the Unrestricted entitlement bypasses everything, so it "should be suppressed for non-admin users" (policy onboarding guidance, blog 2025-04-17). Attribute-key spellings vary across API surfaces: confirm them in your workspace's policy editor before relying on this JSON verbatim.

⚠️ Budgets and policies monitor and constrain; they do not stop a determined spender. Budgets are "monitoring and alerts, not a hard cap" (budgets doc, updated 2026-10-07): a user with sufficient permissions can still create a warehouse that runs long or stays scaled beyond expectations. Databricks' own framing: "Good controls via compute policies, job timeout settings, and budgets help Databricks platform administrators keep spend within spending limits but there is always the possibility of a user with sufficient permissions creating a job or warehouse that runs long or stays scaled beyond expectations and causes an unexpected spike in spending" (top-5 system-table queries blog, 2026-09-22). Guardrails are layered or they are theatre.

---

5. Spot on AWS: what it saves and what it never touches

AWS Spot Instances "save up-to 90% on On-Demand prices" (aws.amazon.com/ec2/spot, read 2026-10), and AWS issues a two-minute interruption notice before stopping or terminating a Spot instance (AWS EC2 docs, read 2026-10). On Databricks the topology rule is fixed: when you tick spot, "driver node is always on-demand, subsequent instances will be spot" (compute configuration doc, updated 2026-10-06).

5.1 Worked example E6: spot arithmetic, and the column it never touches

Five m5.xlarge workers for 200 hours a month (EC2 list, us-east-1, read 2026-10-12):

Four operational facts to price into the design: the driver stays on-demand (compute docs 2026-10-06); the two-minute eviction arrives mid-task, so pipelines need restartable, idempotent stages (AWS docs 2026-10), the AVAILABLE_NOW trigger and checkpointed Structured Streaming from lessons 05 and 13 are the compatible patterns; pools are all-spot or all-on-demand (API adds SPOT_WITH_FALLBACK), and Databricks' guidance is "Do not use a pool with spot instances as your driver type"; and spot saves nothing on serverless, serverless is bundled, and no source states EC2 spot discounts flow through to serverless DBU rates.

• 📚 Did you know? Spot can save up to 90% and still be the wrong call for a 20-minute strict-SLA job: Databricks' current guidance pairs spot pools for cost-tolerant workloads with on-demand pools for short, strict-SLA jobs, and recommends serverless instead of pools wherever the workload supports it (docs, read 2026-10). Spot is a workload decision, not an account-wide savings toggle.

---

6. Right-sizing, autoscaling, pools, and performance-as-cost

6.1 Right-sizing the warehouse (the proportional lever)

For a warehouse, DBU cost is size rate × up-time, so one T-shirt size down is a proportional DBU cut for every hour the warehouse is up: the cleanest linear saving on the platform. The classic/Pro ladder is built on i3.2xlarge workers (2X-Small = 1 worker, doubling to X-Large = 32, up to 4X-Large = 256) with "a cluster for every 10 concurrent queries" as the concurrency rule (docs, read 2026-10). Size to the concurrency you serve, not the peak you once saw; add clusters (warehouse-level autoscaling) rather than inflating the T-shirt for a queue that clears in minutes.

6.2 Autoscaling, pools, and AVAILABLE_NOW

• Autoscaling shrinks the peak. Optimized autoscaling (Premium+) goes min→max in ≤2 resize events, scales down on a 40-second underutilization window for job compute and 150 seconds for all-purpose (docs, updated 2026-10-06). Never combine it with spark.dynamicAllocation.enabled: the docs warn of executor churn and NODES_LOST.
• Pools cost zero DBUs while idle, and full AWS while idle. "Databricks does not charge DBUs while instances are idle in the pool. Instance provider billing does apply" (cost best-practices, 2026-09-11). Size min_idle_instances and idle_instance_autotermination_minutes deliberately; keep max cluster size ≤ pool max_capacity or scale-out fails with INSTANCE_POOL_MAX_CAPACITY_FAILURE.
• AVAILABLE_NOW shapes the pipeline. Run a triggered (Trigger.AvailableNow()) pipeline on a job cluster that terminates at completion instead of a continuous cluster that idles between micro-batches: the official lever list recommends it (best-practices, 2026-09-11).

6.3 Photon as a cost lever (carefully)

Photon is the vectorized C++ engine that "replaces the JVM-based Spark SQL execution engine" while Catalyst still plans the query (Photon docs, updated 2026-09-11). Its cost story is billable seconds, not discount: finishing sooner means fewer per-second-metered seconds, but Photon also "consume[s] DBUs at a different rate than the same instance type running the non-Photon runtime", so "Photon is faster" never implies "Photon is cheaper" (docs; benchmark your own workload). It accelerates SQL, DataFrame ETL and stateless streaming, and does not accelerate Python UDF bodies, RDDs, Datasets or stateful streaming, queries under ~2 seconds see no meaningful gain (docs, 2026-09-11). Photon is on by default on serverless, SQL warehouses and the UI; API-created clusters must set runtime_engine: "PHOTON" explicitly (lesson 06).

6.4 The four-stage loop

Databricks' own frame for controlling spend (Databricks Answers, read 2026-10):

Most teams reverse this order and start at stage 4: rewriting queries while an idle all-purpose cluster bills $0.55/DBU in the corner. Stage 1 and 2 are cheap (the meter data is already in your account); stage 3 is configuration; only stage 4 is engineering.

---

7. Cost attribution: system tables, budgets, and the AWS console

7.1 system.billing.usage: every DBU has an address

The billing system table (docs, updated 2026-10-08) carries, among others: account_id, workspace_id, workspace_name, region, billable_usage_timestamp, billing_origin_time, billing_month, cloud, sku, usage_type, product_feature, record_type, run_as, metered_quantity, list_price, unblended_cost, databricks_contract_quantity, aws_public_list_price and tags. The three that do the work in every attribution query:

• sku / usage_type / product_feature: what kind of compute (jobs vs all-purpose vs SQL vs serverless pipelines);
• run_as: whether the run was interactive, a job, serverless, and so on;
• tags / workspace_name; whose it is.

record_type separates usage rows from price rows, and Databricks ships ready-made joins to system.billing.list_prices and system.compute.clusters, plus instructions to publish the result to an AI/BI dashboard and raise an alert (docs, 2026-09-11). A prebuilt Usage Dashboard exists too (blog, 2026-09-22): start there before writing SQL.

7.2 Worked example E7: the "cut the bill" audit in SQL

Rank the output and work top-down through the lever list: (1) idle all-purpose clusters and their auto-termination setting → (2) warehouses with auto-stop "never" or 45 minutes serving 20-minute dashboards → (3) workloads sitting on All-Purpose that are really jobs → (4) one-size-down / autoscaling → (5) spot for workers → (6) pool the warm nodes → (7) S3 lifecycle + a gateway endpoint → (8) budgets + alerts so it does not regrow. Two supporting tables close the loop: system.billing.list_prices (your contract's prices: the in-account replacement for any public rate table) and system.compute.warehouse_events for warehouse lifecycle forensics.

7.3 Budgets, tags, and the AWS half

Budgets (doc, updated 2026-10-07): up to 1,000 budgets per account, each with up to 4 thresholds (%), expressed in USD at list price including add-ons (no discounts/credits applied), scoped by team/project/workspace with filters, created by account admins (workspace admins for UC-scoped budgets). Again: budgets monitor, they do not cap.

Tags are the joint between the two bills, with a catch. Databricks tags and custom tags enforced via compute policies and serverless usage policies land in system.billing.usage (blog, 2026-09-22), and tag propagation to cloud resources is the documented path to AWS-side attribution (best-practices, 2026-09-11). But a team tag set only on a Databricks cluster does not by itself become an AWS cost-allocation tag; and tags do not backfill, the AWS bill's CostCenter dimension exists only from the day you create it. On the AWS side, Cost Explorer keeps "up to the last 13 months" of history and forecasts "the next 18 months" (AWS docs, read 2026-10).

• 📚 Did you know? New query tags (Public Preview) land in system.query.history, dbt-databricks 1.11.0 adds auto-tagging, and a Governance Hub Cost page (Beta) aggregates the spend surface (Databricks blog, 2026-10-07). RBI rebuilt cost monitoring and forecasting on the system tables and reported it running 3 to 4× faster than their previous process (same blog): the meter data is already in your account; the dashboard is the cheap part.

---

8. The AWS side of the bill: EC2, EBS, S3, NAT, CloudWatch

The AWS Price List offers (us-east-1; EC2 read 2026-10-12, S3 offer published 2026-09-28) and the AWS pricing pages (read 2026-10):

Three quiet leaks live in this table. NAT data processing on S3 traffic: every S3 list/get through a NAT Gateway costs $0.045/GB plus $0.045/h, while an S3 gateway endpoint is free, the single cheapest networking fix on AWS (section 9 uses it). CloudWatch at $0.50/GB ingested is the price of letting driver and cluster logs run unmanaged. And storage waste compounds silently: Databricks' own cost guidance cites a customer bucket of 2.5 PB where only 800 TB was real data and 1.7 PB was old object versions, at $0.023/GB-month that is roughly $39,000 per month of pure waste, deletable by an S3 lifecycle rule without touching a single DBU (cost-management blog, 2022-10-18; S3 rate from the 2026-09-28 offer).

---

9. The monthly TCO case: $3,011 →$1,985 in three levers

9.1 Declared assumptions (AWS us-east-1, list, Oct 2026)

A five-person data team: 21 working days; a shared all-purpose dev cluster (4 × m5.xlarge, emission 12 DBU/h: the illustrative node arithmetic from E1: up 6 h/day); 3 pipelines on jobs compute (4 nodes, 0.5 h/day each, 30 days); BI on a serverless SQL warehouse measured at 2,520 DBU for the month (10 h/day × 21 days at an assumed 12 DBU/h T-shirt emission: confirm the size rate in system.billing.list_prices); 5 TB in S3; 500 GB of NAT processing; 60 GB of logs to CloudWatch.

9.2 The before picture

9.3 Three sourced levers

Read the chart top-down and the strategy appears: the BI line is the whale (59% of the original bill) and falls 40% from one auto-stop setting; the dev cluster falls 33% from auto-termination; the pipelines barely move because they were already on the cheapest SKU (jobs) with structural zero idle. Every account's chart looks different; which is exactly why section 7's attribution step comes before any optimization.

---

10. Storage, layout, and scan: the levers that touch no DBU rate

• S3 lifecycle and versioning hygiene: the $39,000/month version-waste example in section 8 is the template: lifecycle rules delete or tier old object versions at S3 rates ($0.023/GB-month, offer 2026-09-28) and never touch a DBU.
• OPTIMIZE, liquid clustering and partitioning (lessons 04 and 14): fewer bytes scanned per query means fewer billable seconds on a per-second meter, and load-based autoscaling sees fewer peaks.
• Tag propagation to cloud resources (best-practices, 2026-09-11): without it, the AWS half of the bill cannot be split by team at all.
• NAT → gateway endpoint for S3 (section 9) and right-sizing CloudWatch log retention, at $0.50/GB ingested.
• The BI anti-pattern: per-TB intuition does not apply on Databricks: the warehouse bills time × shape, so SELECT * re-scanning 400 GB a hundred times a day bills the same DBUs per scan-window… until the extra work lengthens runtime, trips load-based autoscaling into more clusters, and tips the warehouse into a bigger T-shirt. The cost shows up as shape, not as bytes.

---

11. Real-world proof: what the levers delivered for customers

Documented customer results (all from the Databricks budget/alerts blog, 2026-10-07, unless noted):

• Lumen moved Looker-backed reporting to serverless SQL warehouses and reported compute costs down 30 to 40% with queries ~90% faster against ~7 GB scanned every 10 minutes: the saving came from eliminating idle classic warehouse time and the EC2 bill, not from a discount.
• GetYourGuide ran the same migration pattern on BI serving and reported costs down ~20% with queries ~35% faster.
• RBI rebuilt cost monitoring and forecasting on the system tables and reported 3 to 4× faster than their previous process.

The practitioner bands around these numbers are consistent: quick configuration wins (job-compute migration, auto-termination, spot workers, turning off idle warehouses) are reported in the 20 to 40% range within weeks (DataLane, 2026-04-08; SELECT, 2026-07-16; Cyfra Dane, 2026-07-15: consultant-authored posts, i.e. vendor claims). Everything past that band is workload redesign, not configuration.

Comparative Verdict: Databricks (DBU) vs Snowflake (credits) vs AWS-native (Athena, $/TB scanned)

• Meters. Databricks bills DBU/h of shape plus, on classic, the EC2 bill, two meters, most exposed levers (jobs 0.15 · all-purpose 0.55 · SQL 0.22/0.55/0.70 per DBU, Oct 2026 list). Snowflake bills credits with the machine bundled, X-Small = 1 credit/hour, doubling by size (Small 2, Medium 4, Large 8, X-Large 16), per-second with a 60-second minimum, at $2.00 Standard / $3.00 Enterprise / $4.00 Business Critical per credit on AWS US East (Snowflake service-consumption table + calculator FAQ, read 2026-10). AWS-native, represented by Athena, bills dollars per TB scanned, the official worked examples price queries at $5/TB with a 10 MB minimum per query (aws.amazon.com/athena/pricing, 2026-10), zero idle cost, but orchestration, state and governance are yours.
• Idle. Databricks classic bills EC2 (and DBUs) while up: auto-stop 45/10 min, auto-termination and pools are the defense. Snowflake auto-suspends to zero. Athena has no idle at all. If you leave Databricks compute up, it is the most expensive of the three; if you watch it, job compute is the cheapest long-running engineering meter.
• Illustration (168 h = 8 h × 21 d; meter sizes assumed T-shirts, confirm in-account): SQL Serverless Small 12 × 168 × $0.70 = $1,411.20; SQL Classic 2X-Small 4 × 168 × $0.22 = $147.84 + machine; Snowflake X-Small 168 × $2 = $336 (Standard) and Large 168 × 8 × $2 = $2,688; Athena 1 TB/day × 30 = 30 TB × $5 = $150. Same team, same data, three meters: the number depends on which meter you forget to watch.
• Verdict. Athena wins rare, scan-light, serverless-shaped workloads and loses the moment you need ETL state, streaming or ML. Snowflake has the simplest bill (one meter, self-stopping) and is hard to beat for elastic BI at X-Small: Large sizes. Databricks is the most expensive if left idle and the most economical for long-running engineering + ML on job compute, because the levers: SKU choice, auto-termination, spot, pools, system-table attribution: are exposed at the workload level. Choose the meter you are willing to operate.

2026 Updates (as of October 2026)

---

Real-World Case Studies

📋 Case A: Addepar (wealth management, Cloud: AWS): $2 million off infrastructure, 5× faster delivery Challenge. Engineering and data teams siloed; slow pipeline delivery; rising infrastructure cost on a platform modelling over $8 trillion in investments. Stack on AWS. Databricks running on AWS, Unity Catalog, shared notebooks, Databricks SQL: Cloud: AWS on the story page. Reported outcome. "Addepar models over $8 trillion in investments on Databricks running on AWS. Shared notebooks, Unity Catalog and collaborative data access bring engineering and data teams together in one place, accelerating pipeline delivery by 5x and cutting infrastructure costs by $2 million." (https://www.databricks.com/customers/addepar/aws, undated page, accessed 2026-10). Lesson angle. The classic "unification is the cost strategy" story: one shared platform on one SKU ladder replaced duplicate stacks, and the collaboration metric and the spend metric moved together. Primary lesson mapping: this one (L15), secondary L11.

📋 Case B: Nubank (LATAM fintech, storage on AWS S3): +40% annual cost savings while query volume doubled Challenge. A highly regulated, fast-growing estate (100MM+ customers) needing cost efficiency and continuity through a 12-month warehouse-platform migration. Stack. Databricks SQL and Unity Catalog; the storage layer "mostly is based on AWS in S3" (Databricks Answers transcript, 2026-08-27). Reported outcome. "Zero-downtime throughout the 12-month migration period … Successfully scaling platform to handle 100% query growth (20MM to 40MM monthly queries) … 17k users globally … +40% annual cost savings … Leverage of UC for centralized data governance in highly regulated FSI industry" (https://www.databricks.com/dataaisummit/session/how-nubank-migrated-databricks-sql-reducing-costs-40-and-doubling, undated session page, accessed 2026-10). Lesson angle. Cost per query, not total spend, is the honest metric: total spend roughly flat while volume doubled is a 50%-class unit-cost reduction achieved by migrating to the right meter (Databricks SQL) with governance (UC) attached. Primary mapping: L15; secondary L08 and L11.

📋 Case C: Comcast (communications & media, Cloud: AWS): 10× compute-cost reduction, 640 machines → 64 Challenge. Petabytes of telemetry and billions of voice interactions from 20M+ voice remotes; fragile pipelines; small-file ingestion pain; hundreds of models deployed across cloud, on-prem and edge. Stack on AWS. Databricks, Delta Lake (ingest/enrich/optimize small files), managed MLflow, autoscaling + spot instances, notebooks; Tableau downstream: Cloud: AWS on the story page; listed among customers "already leveraging Databricks on AWS" (press release, 2022-05-10). Reported outcome. "10x Reduction in overall compute costs to process data · 90% Reduction in required DevOps resources"; "Delta Lake has enabled Comcast to optimize data ingestion, replacing 640 machines with 64 while improving performance"; model deployment "weeks to minutes" (https://www.databricks.com/customers/comcast, undated page, story origin 2019, accessed 2026-10). Lesson angle. The cheapest optimization is structural: Delta's file handling collapsed the fleet 10× before any rate or idle-time tuning, and spot instances then attacked the remaining AWS column. Teach the metrics as what Comcast reported at the time (2019-era story), not as current platform capability. Primary mapping: L14; secondary this lesson.

📋 Case D: Lumen and GetYourGuide (from section 11): serverless SQL as a cost cut Lumen's Looker-to-serverless move cut SQL compute 30 to 40% with ~90% faster queries; GetYourGuide cut BI serving ~20% with ~35% faster queries (Databricks blog, 2026-10-07). Both savings are idle-time and fleet-elimination stories: the same arithmetic as worked example E4, at enterprise scale.

---

Practice Questions