Performance-Optimized Serverless Mode for Non-Time-Sensitive Databricks Jobs

Performance-optimized mode, the default, keeps warm compute ready so work starts and runs faster. Standard mode uses less compute and starts within about four to six minutes, and Databricks states that it can reduce costs by up to 70% compared to performance-optimized mode. Both modes bill under the same SKU; standard mode simply consumes fewer DBUs for the same work.

Because performance-optimized is the default, scheduled batch jobs and triggered pipelines often run in it without anyone having chosen it: nightly ETL, hourly aggregations and backfills whose deadlines are measured in hours pay for fast start-up they do not use. Databricks' serverless best practices say that for scheduled jobs where startup latency is not critical, standard mode typically offers the best value. Standard mode is not available for notebooks, and interactive or tightly scheduled time-critical workloads are legitimate reasons to stay on performance-optimized.

Serverless DBUs

Serverless jobs and pipelines are billed in DBUs for the compute used, with infrastructure included in the DBU price

Performance-optimized mode

The default mode; faster startup and execution backed by warm compute, consuming more DBUs for the same work

Standard mode

Same SKU but fewer DBUs, with startup typically within 4 to 6 minutes; available for Lakeflow Jobs and Lakeflow pipelines, not notebooks

performance_target attribute

Recorded in system.billing.usage product_features as PERFORMANCE_OPTIMIZED or STANDARD for each usage record

• Query system.billing.usage where product_features.is_serverless = true and product_features.performance_target = 'PERFORMANCE_OPTIMIZED', grouped by usage_metadata.job_id and usage_metadata.dlt_pipeline_id, to find the jobs and pipelines consuming the most DBUs in performance-optimized mode
• Map those job and pipeline IDs to their schedules and triggers and flag the ones that run on a cron schedule or file-arrival trigger with no tight completion deadline
• Review job settings in the Jobs UI (the Performance optimized toggle on the job details page) or the job definition's performance_target field in the Jobs API or bundle configuration
• For triggered serverless pipelines, check the Performance optimized setting in the pipeline scheduler; for continuous pipelines, check whether they run under a continuous job

• Clear the Performance optimized setting (or set performance_target to STANDARD in the job or bundle definition) for scheduled batch jobs and triggered pipelines that can tolerate a 4 to 6 minute start
• Keep performance-optimized mode for interactive work, jobs chained under tight SLAs, and short jobs where start-up latency dominates run time
• For continuous pipelines that should use standard mode, run the pipeline with a continuous job and clear the Performance optimized checkbox in its schedule, as Databricks documents
• Compare DBUs per run in system.billing.usage before and after switching to confirm savings and check that run completion times still meet downstream deadlines
• Set a team default, for example in bundle templates, so new scheduled jobs start in standard mode unless a latency requirement is documented

• Best practices for serverless computedocs.databricks.com
• Run your Lakeflow Jobs with serverless compute for workflowsdocs.databricks.com
• Configure a serverless pipelinedocs.databricks.com
• Billable usage system table referencedocs.databricks.com
• Databricks Pricing: Flexible Plans for Data and AI Solutionsdatabricks.com