Serverless bills per second and starts almost instantly, which rewards short workloads that spin up and finish. Classic clusters have real startup and idle overhead, but once a cluster's running, flat hourly pricing doesn't care how long the job takes. 30 minutes is roughly where those two economics cross: below it, serverless's speed and per-second billing win; above it, classic's flat rate starts winning instead.

Data volume drives both the compute a workload needs and what that compute costs under each pricing model. Steady volumes are easy to size a classic cluster for once and leave alone. Variable volumes are harder to size correctly on classic: you're either overprovisioning for the peak or getting squeezed during it. Serverless sidesteps that sizing problem entirely by scaling to whatever the workload needs, run by run.

Concurrency determines how much parallel capacity a workload needs at any given moment. Steady concurrency is easy to provision for on classic: size the cluster once and it stays right-sized. Spiky concurrency is where classic clusters either sit idle most of the time or get overwhelmed during bursts, because a fixed cluster can't flex fast enough. Serverless absorbs those spikes automatically, since it scales per request instead of per pre-provisioned capacity.

Serverless compute runs in a shared, managed environment that Databricks controls end to end, which is what makes the instant start and automatic scaling possible. That same managed environment is also why it doesn't support every configuration: GPU access, custom libraries, and fine-tuned runtime settings all require more control over the underlying compute than serverless is built to give you.

This is the question the other four feed into. Duration, data volume, concurrency, and custom requirements all shape the number, but none of them tell you the number itself. Only a real cost simulation, run against this specific workload's actual telemetry, does that.