How it fits together
Scheduling LanceDB’s pods through Slurm puts them under the same scheduler as GPU training jobs, so the cluster’s capacity is accounted for consistently regardless of which one is using it — Slurm’s fair-share and priority policies apply to LanceDB the same way they apply to a training job, including preemption when training needs the capacity back.Why it matters
Most GPU infrastructure already runs Slurm for training. Deploying LanceDB Enterprise into that same infrastructure, under the same scheduler, means it can share capacity with training workloads safely — queued, accounted, and preemptible like everything else — instead of requiring a separate, dedicated pool of nodes carved out just for LanceDB. Combined with multicloud dispatch, that makes it practical to keep your primary deployment wherever it already lives and still reach GPU capacity on a Neocloud built around Slurm, only for the work that needs it. Contact us to learn more about running LanceDB Enterprise on a Slurm-scheduled cluster.What to read next
Multicloud
The cross-cloud dispatch model this page’s Neocloud case builds on.
Architecture
The query, executor, cache and jobs fleets this scheduling applies to.