Booting Databricks VMs 7x Faster with Serverless Engineering Innovations

Overview

Serverless computing promises instant resources on demand, but the reality behind that promise is a lot harder than it sounds. Every time a customer runs a query or job on Databricks Serverless, a virtual machine has to boot, pull the right software, and warm itself up before it’s actually useful, and doing that at the scale of millions of VMs a day, across three major cloud providers, is a genuinely hard infrastructure problem.

Databricks recently shared a detailed look at how its engineering teams tackled this exact problem, cutting VM boot times by a factor of seven, from minutes down to seconds. The result isn’t just a nice performance number; it translates into tens of millions of compute minutes saved every day and a noticeably snappier experience for anyone running Apache Spark clusters, SQL warehouses, or LLM serving workloads on the platform.

Introduction

Where VM Boot Time Actually Goes

Before optimizing anything, Databricks engineers mapped out the boot sequence for a “Databricks VM”, a virtual machine preloaded with Databricks software, into three stages:

1. OS booting — The VM boots its kernel, starts system services, starts the container runtime, and connects to the cluster manager that coordinates the entire fleet.
2. Pulling container images — Once connected, the VM downloads several gigabytes of container images, including the Databricks Runtime itself, as well as supporting utilities for logging, health monitoring, and metrics.
3. In-container setup — Finally, the workload container initializes. For Databricks Runtime specifically, this means loading thousands of Java libraries and running warm-up queries so the JVM’s just-in-time (JIT) compiler can convert bytecode into optimized native instructions before a customer’s first real query ever runs.

Each of these stages, left unoptimized, adds real minutes to the boot process. Databricks tackled all three independently.

A Purpose-Built Serverless OS

Because Databricks controls the entire software stack for its Serverless offering, engineers built a stripped-down, purpose-specific operating system rather than relying on a generic one. The guiding idea was simple: include only what’s strictly necessary to run containers and reorder the boot sequence so critical services start earlier.

This meant removing components that have no place on an ephemeral cloud VM, such as the USB subsystem, thereby shrinking the OS image and making it easier for cloud providers to cache efficiently. The team also tuned I/O behavior, favoring buffered writes over synchronous ones and reducing blocking during image pulls and container creation. Since these VMs are short-lived and disposable, the usual caution around data durability in the event of crashes or power loss simply doesn’t apply, freeing the team to optimize aggressively for speed.

A Lazy Container Filesystem

The second bottleneck was container image downloads. Pulling several gigabytes of images can take minutes, even on fast connections. Still, prior research cited in the post found that containers typically need only about 6.4% of their image data to start doing useful work. Most of an image’s contents simply aren’t touched right away.

Databricks built a lazy container filesystem to exploit this. Container images are converted at build time into a block device format that supports on-demand loading in 4 MB sectors. When a VM pulls an image, it only fetches the metadata needed to construct the container’s directory structure, filenames, permissions, and layout, and immediately mounts a virtual block device. The container starts running right away, and only when the application first reads a file does the system fetch that specific block of data from the remote registry, caching it locally to avoid repeated network trips.

Checkpointing and Restoring a Pre-Initialized Container

The final, and arguably most involved, optimization tackles the in-container setup, specifically the expensive process of warming up the JVM for Databricks Runtime. Rather than repeating this warm-up procedure from scratch for every single VM, Databricks now takes a full checkpoint of an already-initialized container and uses it as a template for future launches.

During checkpointing, the container runtime freezes the entire process tree. It saves everything needed to reconstruct that exact state later: loaded libraries, open file descriptors, the full JVM heap (including JIT-compiled native code), stack memory, and any files created during setup. This checkpoint is then packaged as a standard OCI/Docker-compatible image and distributed through the same container registry used for regular images. Future VMs can “restore” into this pre-warmed state instead of repeating the setup process.

Conclusion

Cutting VM boot time by 7x is the kind of improvement that customers experience as “Databricks just feels fast,” without ever seeing the layers of engineering underneath, a custom-built OS, a lazy-loading container filesystem, and a checkpoint/restore system for pre-warmed runtimes. Each optimization on its own solves a different bottleneck in the boot sequence, and together they turn a process that used to take minutes into one that takes seconds.

It’s a good reminder that the “serverless” experience customers take for granted is built on genuinely hard, unglamorous systems engineering, and that investing in it pays off across the entire platform.

Drop a query if you have any questions regarding Databricks, and we will get back to you quickly.