Serverless platforms promise elasticity, but in practice they keep many idle sandboxes warm in memory to hide slow cold starts. The root cause is that each function runs in a container or VM that has to boot a guest OS and set up networking to provide a POSIX-like interface.

Dandelion rethinks this interface for cloud-native applications. Applications are expressed declaratively as DAGs of system-provided communication functions (e.g. HTTP calls to storage, databases, or AI inference services) and pure compute functions, untrusted user code with declared inputs and outputs. Since compute functions never perform I/O themselves, they run in lightweight sandboxes that cold start in hundreds of microseconds. This makes it practical to boot a fresh sandbox for every request, reducing performance variability by two to three orders of magnitude compared to Firecracker and cutting committed memory by 96% on average on the Azure Functions trace.

Cloud analytics systems have to serve both small queries that easily fit on one machine and large ones that need the memory, compute, and I/O bandwidth of many. Single-node engines such as DuckDB are highly efficient but cannot scale out, while distributed engines such as Trino scale out but pay for distributed coordination and data exchange even on small queries.

Plume bridges this gap with a declarative interface between the query engine and the cloud runtime. It takes query plans optimized by DuckDB and lowers them into DAGs of fused operator stages that declare their dependencies, inputs, partitioning constraints, and available parallelism. The Dandelion runtime then decides at execution time how to run them, using live information about utilization, queueing, and data locality to keep stages together on a single machine or spread them across workers when scaling out pays off. Plume keeps the low latency of a single-node engine for small queries, matches Trino on most larger ones, and shares resources efficiently across bursty, multi-tenant workloads.