Engines and scaling

Promenade runs the same workspace against three kinds of execution target. The analysis is identical in all three; only where the computation happens changes.

The three tiers

Tier	Runs on	Suits
Browser engine	The tab you already have open	Anything up to roughly 20–50 million events
Local Docker engine	One container on your own machine	Gigabyte logs; native plugin runners, real threads, spill-to-disk
On-prem or cloud engine	The identical image, next to your data	Terabyte-scale, and data that may not leave its environment

Why the browser has a ceiling

DuckDB-wasm cannot spill to disk. An aggregation that exceeds available memory does not run slowly — it aborts. That is what puts the practical limit at tens of millions of events rather than at some soft performance boundary.

Below that limit the browser is the better place to work: no infrastructure, no data movement, and no transfer of custody.

What stays the same

Crossing the boundary does not change how you work:

• the same artifact tree,
• the same plugins, unchanged — the identical bundle executes in a sandbox on the engine,
• the same actions and views,
• one provenance graph spanning all of them.

An artifact stored on an engine appears in the same tree with a badge, not in a separate list.

Data locality follows execution

When work runs on an engine, the bulk data stays there. Only metadata, previews and the paged results you actually look at cross the network.

That is what makes a very large log workable over an ordinary connection — you are never downloading it — and it is also what keeps regulated data inside its own boundary while you analyze it.

Adding an engine

Engines are managed from the compute control in the top bar. A local Docker engine is a single self-contained container rather than a Compose stack, deliberately: every additional moving part is one more thing to understand before the feature works.

Once an engine is connected, actions gain a target selector — you choose where a given action runs.

A workflow that works

1. Profile a sample locally. Import a slice into the browser and get the analysis right where iteration is fastest.
2. Move to an engine for the full log. Run the identical chain of actions against the whole dataset.
3. Bring the results back. Models, alignment sets and aggregates are small; the log stays where it is.

Reproducibility

Every execution records the runtime and version that produced it, including which engine ran it. A result computed on a cloud engine is as traceable as one computed in the tab, and the record tells them apart — which matters when someone asks whether a figure came from the sample or the full log.