Databricks Serverless: Questions After You're Live

Catch the drift early, ^{not after it costs you.}

A workload that looked healthy at launch can quietly drift months later as data volume, usage, or query patterns change. Native tooling shows you the bill after the fact. It won't show you what's shifting underneath it as it happens.

The same four checks apply to every workload you're running, not just the ones you just migrated. Native tooling shows you what's happening today if you go looking; it won't tell you whether that's a change from where you started, or catch the drift before it shows up as a bigger bill. Here's what that gap looked like for one real workload, then the breakdown for each check below.

Real example

+164% monthly cost, launch vs. month 4

A workload that looked healthy at launch, running well within budget. Over the following months, usage grew and query patterns shifted, and the warehouse kept auto-scaling to keep pace. Nobody was watching the trendline, so the drift didn't show up until the quarterly bill did: $2,400 a month at launch, $6,340 by month four, a 164% jump with no single change anyone could point to.

Critical Questions to Answer

What drifts, why, and ^{how to catch it.}

Each question below is one of the checks a workload needs after it's live, how far Databricks native tooling gets you toward catching it, and what only Unravel can tell you.

Cost & performance drift

Is its cost or performance still where it was at launch?

Serverless bills and scales dynamically, so a workload's cost and performance profile isn't fixed at go-live, it moves with usage. Billing and query history are there to look at, but nothing about serverless flags on its own when a workload has quietly drifted from where it started. That comparison only happens if someone thinks to make it.

Yes

Cost and performance in line with launch

No drift detected. This workload is running as expected.

Cost or performance has shifted

Drift detected. Investigate what changed before it compounds.

Answerable by

Native Databricks

◐ Partial

Billing and query history are there if you go looking, but nothing compares today's numbers against the workload's own launch baseline automatically.

Unravel

✓ Yes

Tracks each workload's cost and performance against its own launch baseline continuously, and flags drift as soon as it starts, not once it shows up on the bill.

Volume & usage change

Has its data volume or usage pattern changed since going live?

Serverless absorbs data volume and usage growth seamlessly, that's the whole point, but the seamlessness also hides that the workload itself has genuinely changed. A workload that was a small, variable batch job at launch can quietly become a regular 10GB+ job, crossing the exact threshold that made it a good serverless fit in the first place, with nothing forcing anyone to notice.

Yes

Volume and usage still match the launch profile

Still a good fit. No re-evaluation needed.

Volume or usage has grown or shifted

Worth re-checking. The original fit decision may not hold anymore.

Answerable by

Native Databricks

✕ No

Auto-scaling absorbs volume growth silently by design. There's no native alert when a workload's usage profile has meaningfully changed.

Unravel

✓ Yes

Compares current data volume and usage patterns against the workload's original profile, and flags when they've moved enough to warrant a second look.

Sizing match

Is its warehouse sizing still matched to how it's actually used?

Auto-scaling adjusts a warehouse to current load, but the scaling bounds themselves, the minimum and maximum it's allowed to reach, are usually set once at launch based on early assumptions and rarely revisited. As usage evolves, a warehouse can end up running well outside its efficient range: overprovisioned and paying for headroom nobody uses, or underprovisioned with latency quietly creeping in.

Yes

Scaling bounds match current usage

Sizing is still right. No change needed.

Scaling bounds don't match current usage

Resize needed. Bounds set at launch may no longer fit actual load.

Answerable by

Native Databricks

◐ Partial

Warehouse configuration is visible, but nothing tells you whether the bounds you set at launch still make sense against current usage.

Unravel

✓ Yes

Continuously compares each warehouse's configured scaling bounds against its actual usage pattern, and flags when they're out of sync.

Trend visibility

Would you notice if it started trending worse?

This is the question the other three feed into. It's not about any one metric, it's about whether anyone is actually watching. Native tooling requires someone to proactively check dashboards or billing; there's no default trend layer that surfaces a slow decline before it turns into a quarter-over-quarter budget conversation.

Yes

Actively monitored with trend alerts

You'd catch it early. Trend monitoring is in place.

No active trend monitoring

You wouldn't catch it until the bill. Drift compounds silently until someone looks.