What are the limits, and how does it scale?
This answer is still being written. Three limits are documented and settled, and they are below. Sizing guidance (throughput, how many boxes, what a managed Postgres needs) is not written yet, and we would rather leave it blank than print a number you would size a deployment on.
A step has a time ceiling. One 'use step' runs inside a single delivery to
the runtime, capped at 15 minutes by default. The ceiling bounds the whole
round-trip, so it bounds the step body and any model call inside it. Raise
WORKFLOW_HTTP_TIMEOUT_MS on the deployment when a step needs longer, such as
one long model call over a large input. A value below 1 second is
clamped up to 1 second; an unreadable value falls back to the default.
Prefer splitting the work across steps where you can. Each step gets its own ceiling, and the runtime records each finished step durably, so a failure later in the workflow does not repeat it.
A failed step retries, but a timed-out one never does. The default policy is 5 attempts with exponential backoff from 1 second, and it covers a handler that threw and a connection that was refused. The runtime abandons a step that runs past the time ceiling and does not retry it: aborting the request only closes the socket, the abandoned copy keeps running to completion, and a retry would put a second copy beside it.
Runs of one workflow go in parallel by default. Trigger the same workflow
three times and three runs start at once. When two copies must never overlap,
mark the workflow executionMode: 'serial' and its runs go one at a time in
arrival order, with the waiting triggers held in a durable queue.
Read more
- Workflows: the execution model and the step ceiling in context.
- Serial execution: when to take runs off parallel, and what it costs.
- Where does my data live?: the services you size yourself.