Declarative analytics is an approach where you describe what your analytics system should be, not how it should run. You declare your data models, tables, transformations, dependencies, and schedules. The system derives the execution from those declarations. Nothing about how the work runs is coded by hand.<\/p>\n\n\n\n
That is the whole idea. The rest of this post explains what it looks like in practice and why it changes the economics of running analytics.<\/p>\n\n\n\n
A decade ago, infrastructure teams stopped writing scripts that provisioned servers step by step. They started describing the desired state of their environment in configuration, and tooling converged the environment to match. Nobody who made that shift went back.<\/p>\n\n\n\n
Analytics is making the same shift now. Most analytics systems today are still imperative. Someone writes code that says extract this, transform that, load it here, in this order, at this time. Every pipeline is a small program. Every change is a code change. Every new customer, source, or schedule means more of it.<\/p>\n\n\n\n
Declarative analytics removes that layer. You state the outcome. The runtime works out the steps.<\/p>\n\n\n\n
Five things, in practice.<\/p>\n\n\n\n
Everything else is the runtime’s job. Orchestration, retries, scaling, logging, and tenant isolation are derived, not configured piece by piece.<\/p>\n\n\n\n
| Imperative pipelines<\/th> | Declarative analytics<\/th><\/tr><\/thead> |
|---|---|
| You write execution code<\/td> | You write declarations<\/td><\/tr> |
| Order of operations is coded by hand<\/td> | Order is derived from declared dependencies<\/td><\/tr> |
| A change means editing and redeploying code<\/td> | A change means updating a declaration<\/td><\/tr> |
| Failures surface wherever the code allows<\/td> | Failures are visible because the runtime knows every step<\/td><\/tr> |
| Each new source or customer adds code<\/td> | Each new source or customer adds metadata<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n The practical consequence sits in the last row. In an imperative system, growth means more code to maintain. In a declarative system, growth means more declarations for the same runtime to execute. The maintenance load stays flat.<\/p>\n\n\n\n Where does the execution come from?<\/h2>\n\n\n\nFrom metadata. The declarations you write are stored as metadata, and the runtime reads that metadata to decide what runs, in what order, and for which tenant. Metadata is the control plane.<\/p>\n\n\n\n This is not a theoretical design. The execution model behind this approach has run in production since 2018, serving every customer of a multi-tenant system through a single engine, maintained by one person.<\/p>\n\n\n\n |