When you hand a program to a cluster engine versus a statement to a query service, who owns the storage, the plan and the capacity?

## Two different things you can hand over When work outgrows one process, there are two quite different bargains on offer, and candidates usually describe them by size when the real difference is **who owns what**. A **cluster execution engine** is a system you hand a whole program to. It takes that program, splits its work across many machines, runs the pieces and puts the results back together. The program is yours: you chose the language, you chose the libraries inside it, and you decided what it reads and where it writes. A **managed query service** is a system you hand a **declarative statement** to — a description of the result you want, not a procedure for producing it. It owns its own storage, its own plan and its own capacity. You never size the machines and you never see them. Everything else about the choice follows from three ownership questions: who holds the bytes, who chooses the strategy, and whose hardware runs it. ## The ownership table | What is owned | Cluster execution engine | Managed query service | |---|---|---| | **Storage** | Not the engine's. You point the program at shared storage, at files, at an outside system; the engine keeps no durable copy of its own by default, and where a storage layer ships alongside the cluster it is still yours to operate | The service's. Tables live inside it, in its formats, under its access control, and reaching them from outside is a deliberate export | | **The plan** | Split between you and the engine. Your program's structure fixes the shape. How much the engine then rewrites varies widely: a declarative surface is rewritten aggressively, per-record code you wrote is executed close to literally, and the oldest model in this family rewrites almost nothing | The service's alone. You supply intent; the strategy is chosen for you, and you influence it only by changing the statement | | **Capacity** | Attributable to you. On some supply models you choose the number and shape of workers directly; on others you supply a hint and a platform sizes from it; a few accept no sizing at all and bill by work consumed. What is constant is that the machines are part of your deployment | Never yours. You cannot count the machines, name one, or attach anything to one | | **What you hand over** | A program, in a general-purpose language, with its dependencies packaged alongside it | A statement naming a result | | **What fails** | Your code, on machines you can identify | A statement, inside a system whose internals you are not shown | ## Why ownership is the axis that pays Four practical consequences drop straight out of that table, and they are what an interviewer is listening for: - **Dependencies.** If the work needs a library — a decoder, a model, a bespoke parser — it needs a runtime that can load it next to the data. Owning the program means owning that freedom. - **Inputs.** A service can only read what it has a reader for. A program can read anything you can write code against, including an outside system reachable only over the network. - **What you can inspect.** When a program is slow you can look at the machines running it. When a statement is slow you have exactly the information the service chooses to publish about that statement. - **How the bill is denominated.** One arrangement bills you for machines that exist; the other bills you for work a statement consumed. They are different meters, and comparing them requires converting one into the other rather than reading the two numbers side by side. ## Where the line genuinely blurs This is the part candidates get wrong, so say it out loud: 1. **Engines accept declarative statements too.** Most cluster execution engines have a SQL surface. Writing SQL therefore tells you nothing about which arrangement you are in — the language is not the dividing line, ownership is. 2. **Query services run user-supplied code.** Many accept functions written in a sandboxed language runtime. What such a function may load, how long it may run and what it may reach out to varies enormously between services, so "it can run code" is never a yes or no; it is a question about this service and this dependency. 3. **Some engines show you no machines either.** There are offerings in this class that accept no sizing and bill by work consumed, which removes the capacity half of the distinction while leaving the storage and program halves intact. The blurring does not dissolve the axis. It means you must state which of the three ownerships you are relying on in a given argument, rather than reaching for the brand of the thing. ## What the distinction actually decides 1. **Whether the work is expressible at all** in what the service accepts, including its function surface. 2. **Whether the data has to move**, and in which direction — the pull toward a service is strongest when the inputs already live inside it. 3. **Who can operate it**: a program on a cluster needs someone who understands a distributed runtime; a statement needs someone who understands the data. Answer the ownership question first, and the rest of the choice becomes arithmetic rather than opinion.