The Cost Iceberg: Visible Compute vs Hidden Everything

Estimated read: 3 min

An Oracle license invoice was blunt: one number, once a year, and everyone budgeting against it knew exactly what they were paying for. A Databricks bill is a different shape entirely – it’s usage-metered, itemized down to the workload, and that itemization is exactly what makes it easy to misread. Most first-time cost reviews stop at the number that’s easiest to find – cluster compute, the DBUs (Databricks Units) burned by running clusters – and declare the migration cost-controlled. That’s the visible tip of the iceberg. Everything below the waterline is what actually decides whether the platform is cheap or expensive to run.

Below that waterline: serverless SQL warehouse spend that never shows up on a cluster event log because there’s no cluster to look at; storage costs from tables nobody VACUUMs and Delta history nobody prunes; idle compute from all-purpose clusters left running between interactive sessions; Photon licensing baked into the DBU rate rather than billed separately, invisible unless you know to look for it; and cross-cloud egress when a pipeline reads from one region and writes to another because nobody checked. None of these appear on the same dashboard as “compute,” so a FinOps review that only tracks compute is reading roughly half the invoice.

                    ▲
                   ╱ ╲     <- Cluster compute (DBUs): visible, easy to track
                  ╱   ╲
                 ╱─────╲   <- waterline: most cost reviews stop here
                ╱       ╲
               ╱ storage ╲     <- untracked Delta history, orphaned checkpoints
              ╱  idle     ╲    <- all-purpose clusters left running
             ╱   Photon    ╲   <- bundled into DBU rate, not itemized
            ╱    egress     ╲  <- cross-region/cross-cloud reads and writes
           ╱──────────────────╲

The reason this matters more in a migration than in a mature Databricks estate: migrated workloads carry forward legacy habits. A nightly batch job that ran on a fixed, pre-provisioned Oracle server for a decade doesn’t automatically know to scale down or auto-terminate on Databricks – someone has to actively design for that, and until they do, the workload is paying compute-cluster prices for what used to be sunk hardware cost. The next few lectures work through the specific levers – compute type selection, cluster policies, and Photon’s memory behavior – that turn “hidden everything” back into something you can see and control.

Before optimizing anything, get visibility first: system.billing.usage (covered in depth in the FinOps section ahead) is the single source of truth for every one of these cost categories, broken out by SKU. Optimizing compute while storage and idle-cluster costs go untracked is optimizing the 20% of the bill you can already see.

See the Databricks pricing overview for how DBU rates vary by compute type and SKU, which is the foundation for the compute arbitrage decision in the next lecture.

| ← Previous: The Cost Iceberg and Compute Arbitrage | Next: Compute Arbitrage: Jobs vs All-Purpose vs Serverless → | |:—|—:|