Scalability study

Outscaling Flyte v1

Flyte v2’s per-action architecture runs common patterns up to 6.5× faster — and removes v1’s single-process memory cliff entirely.

Orchestrator scalability study | 8 GiB engine pod · AWS EKS | core-sleep leaves — no task pods

AbstractFlyte's original engine (v1) represents each run as a single custom resource that one controller reconciles in its entirety on every loop — simple, but it couples a run's cost to the size of one object and concentrates all of a run's state in one shared, memory-bounded process. The redesigned engine (v2) instead decomposes a run into many small actions, each independently reconciled, so no single in-memory object holds the whole run. Benchmarked on identical 8 GiB engine pods across wide fan-out, sustained concurrency, and long sequential chains, v2 completes the common patterns 4.3–6.5× faster and, critically, exhibits no single-process memory cliff: its footprint stays flat at ~0.3 GiB regardless of a run's width, whereas v1, holding a whole run in one object, drives the shared pod into the 8 GiB ceiling and OOM-kills at a ~6,000-leaf fan-out — an outage that takes down the whole platform, not just the offending run.

Read the full paper (PDF) ↗

6.5×

faster on a 500-node sequential chain

~6,000

held leaves before v1's single CRD OOM-kills its pod

0.3 GiB

v2's flat engine footprint, at any run width

1.7×

faster on sustained concurrency to 40,000 held tasks

Key results

What the numbers show

Every chart below is drawn straight from the measured data in the paper — hover any bar or point for the exact value.

One run, N parallel leaves — execution secondsFig. 1 · wide fan-out

Flyte v1Flyte v2

A fan-out puts thousands of actions live at once, so a scaled-out engine has something to parallelize. At 6,000 leaves v2 is 2.0× faster — and that's before the memory cliff below even enters the picture.

Engine memory under held fan-out — the reliability gapFig. 2 · the OOM cliff

Flyte v1Flyte v2

v1 holds a whole run's live leaves in one custom resource, reconciled in a shared 8 GiB pod — engine memory tracks run width. By ~6,000 held leaves it hits the ceiling and is OOM-killed (exit 137), taking the co-located control plane down with it. v2's footprint is decoupled from the run: flat at ~0.3 GiB regardless of width.

N sequential nodes — execution secondsFig. 3 · long chain

Flyte v1Flyte v2

v1 re-reconciles one growing object on every loop, so a long chain pays repeatedly to re-evaluate an ever-larger record; v2 advances one compact action at a time. At length 500, v2 is 4.4× faster.

K workflows × 1,000 tasks, held 120 s — wall-clockFig. 4 · sustained concurrency

Flyte v1Flyte v2

Run at matched parallelism, both engines complete every run and scale sub-linearly — the shape where the two designs are closest. v2 still holds a modest 1.2–1.7× edge across the range.

See it for yourself

Spin up a real Flyte cluster in minutes and run the same workloads on your own hardware. No infra to provision, no YAML to write first.

Try the Devbox

Outscaling Flyte v1

What the numbers show

See it for yourself

Introducing Union.ai
The enterprise Flyte platform

Platform

Resources

Docs

Social

Outscaling Flyte v1

What the numbers show

See it for yourself

Introducing Union.aiThe enterprise Flyte platform

Platform

Resources

Docs

Social

Privacy Preference Center

Manage Consent Preferences by Category

Introducing Union.ai
The enterprise Flyte platform