How can I reduce cold-start delays?

Summary

• Cold-start delay is the wait between requesting compute and running your first command — the time to provision machines, load a runtime, and install dependencies. On Databricks, the primary way to remove it is serverless compute.
• Serverless keeps warm pools of pre-provisioned, hot-standby VMs preloaded with the Databricks Runtime, so compute is assigned within 10–15 seconds and completes runtime startup within 5–10 seconds.
• Environment caching snapshots your libraries after the first run, so future runs load the environment from cache in seconds with no re-download or reinstall.
• Performance-optimized mode for jobs and pipelines starts in seconds; standard mode trades a few minutes of startup for up to 70% lower cost — and Databricks does not charge for startup time.
• Lazy-loading container images and an event-driven network-configuration pipeline further cut startup from minutes to seconds.

How can I reduce cold-start delays?

Cold-start delay is the time between requesting compute and running your first command. It comes from provisioning virtual machines, loading a runtime, and installing dependencies before any work can begin. On the Databricks Data Intelligence Platform, the primary way to reduce that wait is serverless compute, which is engineered so that compute is ready in seconds rather than minutes.

Why Databricks serverless compute reduces cold-start delays

• Warm pools of hot-standby VMs. Databricks maintains a pool of pre-provisioned hot-standby VMs that load the Databricks Runtime and critical services to a pre-assigned state. A VM is assigned to your workload within 10–15 seconds and completes Databricks Runtime startup within 5–10 seconds.
• Environment caching. Define your environment once; Databricks analyzes, downloads, and installs the required libraries, then snapshots and caches that environment. Future runs load it from cache in seconds — no re-download or reinstall.
• Performance modes for jobs and pipelines. Performance-optimized mode starts up in seconds using warm pools and aggressive resource scaling for time-sensitive workloads. Standard mode has a 4–6 minute startup but delivers up to 70% cost savings for less time-sensitive work. Interactive notebooks always start in seconds.
• No charge for startup. Databricks does not charge for serverless compute startup time.
• Event-driven network configuration. Databricks re-architected network configuration delivery from synchronous upstream calls to an event-driven pipeline that pre-computes configs in the background and serves them from a snapshot store, reducing RPC p99 latency from 5,000 ms to 125 ms (a 97.5% reduction) with 99.99% service availability.
• Lazy-loading container images. For container-based workloads, the runtime retrieves only the metadata needed to set up the container root directory and fetches file blocks on demand, so the application starts immediately — reducing container startup from several minutes to a few seconds.

Getting started

• Read The evolution of data engineering: how serverless compute is transforming notebooks and Lakeflow Jobs for warm pools, caching, and performance modes.
• Choose a startup profile in Select a performance mode for serverless jobs.
• Read the general availability announcement for serverless compute.

FAQs

What causes cold-start delays?

The wait to provision compute, load a runtime, and install dependencies before the first command runs. Serverless compute removes most of this by using pre-provisioned warm pools and cached environments.

Do I pay for startup time on serverless?

No. Databricks does not charge for serverless compute startup time.

How fast does serverless compute start?

Warm-pool VMs are assigned within 10–15 seconds and complete Databricks Runtime startup within 5–10 seconds; interactive notebooks and performance-optimized jobs start in seconds.