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.
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.
The shift infrastructure teams already made
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.
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.
Declarative analytics removes that layer. You state the outcome. The runtime works out the steps.
What do you actually declare?
Five things, in practice.
- Data models.ย The structure your data should arrive in.
- Gold tables.ย The final, business-ready tables your reports and tools consume.
- Transformations.ย The logic that turns raw data into those tables, written in standard SQL.
- Dependencies.ย What must be ready before what.
- Schedules.ย When things should be current.
Everything else is the runtime’s job. Orchestration, retries, scaling, logging, and tenant isolation are derived, not configured piece by piece.
How is this different from a pipeline?
| Imperative pipelines | Declarative analytics |
|---|---|
| You write execution code | You write declarations |
| Order of operations is coded by hand | Order is derived from declared dependencies |
| A change means editing and redeploying code | A change means updating a declaration |
| Failures surface wherever the code allows | Failures are visible because the runtime knows every step |
| Each new source or customer adds code | Each new source or customer adds metadata |
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.
Where does the execution come from?
From 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.
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.
VisoFlow is a managed data product. You define the system. VisoFlow runs it. Your declarations stay in standard SQL, which means the logic is portable and the people who already know your data can work with it directly. No new language to learn. No proprietary format that locks your logic in.
Frequently asked questions
Is declarative analytics the same as declarative ETL?
Declarative ETL usually means configuring individual transformations declaratively. Declarative analytics goes further. Models, tables, transformations, dependencies, and schedules are all declared, and the entire execution is derived from them.
Do I need to learn a new language?
No. In a well-designed declarative analytics system, standard SQL is the interface. If your team can query the data, they can define the system.
Does declarative mean giving up control?
The opposite. Declarations are explicit, versioned, and auditable. In imperative systems, intent is buried inside execution code. In declarative systems, intent is the artifact itself.
What happens when something fails?
Because the runtime derives the execution, it knows every step, every dependency, and every run. Failures are visible by default instead of being discovered downstream in a broken report.
The closing thought
If your team spends more time keeping pipelines running than improving what they produce, the problem is not the logic. It is that the execution is coded by hand.
See how a declarative runtime handles it: visoflow.net/how-it-works
Leave a Reply