News: Databricks changed their SQL pricing - good or bad for users?

Alright, settle in. Saw the announcement from Databricks about the shift from DBUs to "Databricks Compute Units" for their SQL offerings. The marketing spin is predictably sunny, but let's scrape the varnish off this and see what the wood looks like underneath.

For those who haven't waded through the docs, the old model charged you for SQL Warehouses based on Databricks Units (DBUs), which were a murky, platform-specific metric. You sized your warehouse (Small to 5XL), it ran, you got billed per DBU per hour. The new model introduces "Databricks Compute Units" (DCUs). They're claiming it's simpler and more predictable because it's directly tied to the underlying cloud VM size. You pick a VM series (Standard, High Concurrency, etc.), it has a fixed DCU/hour rate.

Here's my immediate read, based on two decades of watching vendors "simplify" pricing:

* **The Illusion of Transparency:** Tying a charge to a known VM size (e.g., an m5.4xlarge) *feels* more transparent than DBUs. But remember, you're not renting the raw VM from Databricks. You're renting a managed service that runs *on* that VM. Their DCU rate includes their software, management, and profit margin. You still can't compare it directly to the raw EC2/GCP/Azure cost, which is the baseline they don't want you focusing on.
* **The Real Question: The Ratio.** The only metric that matters now is the DCU-to-VM-cost ratio. If a "Standard" tier uses an m5.4xlarge (16 vCPUs) and costs, say, $0.60/DCU-hour, and a DCU represents one vCPU-hour (they haven't explicitly stated this, watch for the weasel words), then you're paying $9.60/hour for that VM. Go check what an m5.4xlarge costs on-demand in your region. The delta is your "Databricks tax." Has that tax gone up or down? That's the analysis we need.
* **Hidden Cost Shifts:** They're pushing the "simpler" angle, but watch for the new pressure points. With DBUs, scaling was somewhat abstract. Now, with direct VM sizing, the temptation (and the support recommendation) will always be to scale *up* to a bigger instance type for performance. "Your query is slow? Move from Standard to High Memory." That's a steeper jump in DCU/hour cost. The coupling to concrete VM specs makes the financial impact of performance tuning much more direct, which can be a good or a bad thing depending on your team's discipline.
* **The "Predictability" Trap.** Yes, a fixed DCU rate per VM size is more predictable than variable DBU consumption... if your workload is constant. But most analytical workloads aren't. The predictability is on the unit cost, not your total bill. If the new model incentivizes you to run larger, more expensive warehouses to avoid performance complaints, your total bill becomes *less* predictable.

My gut feeling? This is a maturation move. They're standardizing their internal cost accounting and passing on a cleaner, but not necessarily cheaper, structure. The winners will be large, stable workloads where the ops team can precisely map VM needs to DCU rates. The losers will be variable, bursty workloads and teams without fine-grained cost monitoring who will now see the sticker shock of individual VM decisions in stark detail.

I want to see real examples. If anyone has done a preliminary analysis comparing their old DBU burn on, say, a Medium 2-cluster warehouse to the new DCU cost for the supposedly equivalent VM family, post the numbers. The devil is in the unit economics, not the press release.