One pool. Every workload.
Run search, AI, analytics, and scheduled work without sizing a separate cluster for each. The mesh assembles the compute each job needs from one pool, then releases it when the work is done. You size that pool once, and it replaces an overprovisioned fleet.
The whole seam works the question.
Search, AI, analytics and the lake do not call each other as services. They share one substrate and one pool of compute, so a question engages all of them at once rather than being handed between them.
Planned once, spread across the mesh. The planner decides how many nodes the question needs.
Not bolted to the front of it. The planner and the model are one system.
Results, fragments and columns. Overlapping work is served from what was already read.
AI, the lake and compute share one budget, so a heavy question starves nothing behind it.
Every job on the right machine.
A distributed SQL engine rides the mesh, built for one job: answering across the whole record without you deciding first which part of it to keep. It spreads a search across as many nodes as the question needs and hands them back when it finishes. It starts at one or two, scales as far as your budget says, and a node is any size you choose, 8 cores to 192 with memory to match, so a big question gets a bigger machine rather than more small ones.
The same board composes every shape: the pads that fan out for a scan regroup into a multi-stage tree a moment later, and that tree gathers into the same heavy machines that take deep analytics whole.
Capacity stops being your problem.
You plan the pool once. Nothing after that waits on capacity.
Big questions are not slow questions
A search across the whole record gets more nodes, not more time.
You size the deployment, not each workload
New workload, new source, new team. They draw on the pool you already run.
A surge is absorbed, not scheduled
An incident spikes demand and the mesh answers it. Nobody gets paged about capacity.