Catalyst Workflows benchmarks
This page presents the results of a benchmark campaign measuring Catalyst Workflows throughput, latency, and reliability under sustained load, overload, and failure injection. It also shows how Catalyst compares with Dapr open source running on identical infrastructure, so you can judge what the platform delivers beyond a self-managed deployment.
Headline results
| Metric | Result |
|---|---|
| Sequential workflow throughput (5 activities per workflow) | 530 workflows/sec sustained |
| End-to-end workflow completion latency, warm | p50 25ms / p99 31ms |
| End-to-end latency at 350/sec sustained | p50 33ms / p99 54ms |
| Completion ratio under fault injection (~1.7M workflows) | 100% |
| Durable timers and external events under fault injection | 30,000/30,000, zero loss |
Test environment
- Two identical Amazon EKS clusters in a single availability zone, so cross-zone variance is eliminated by design.
- System under test: 3x m7i.2xlarge nodes (8 vCPU / 32 GiB) running 3 sidecar replicas, plus a dedicated m7i.2xlarge PostgreSQL node.
- Storage: io2 Block Express volumes with 10,000 provisioned IOPS.
- Load generation: an isolated m7i.xlarge injector node using open-loop arrivals with 30-60s ramps; the load generator never shares CPU with the system under test.
- Payloads are 128 bytes unless a table says otherwise.
The benchmarks use three workflow shapes:
- Noop: create and complete a workflow with no activities.
- Sequential 1xN: N activities executed one after another, each echoing the payload.
- Fanout-W: W activities executed in parallel, each echoing the payload.
Measurement methodology
Every published number comes from a gate-clean window: completion ratio at or above 0.995, zero arrival drops on the load generator, and fresh state between windows (state store reset, scheduler queue truncation, full restart of the system under test, and a settle period). Windows are preceded by a warm phase. Latency is the end-to-end complete-workflow time observed by the client, from the schedule call to the observed terminal state, not an engine-internal number.
Max sustainable rate (MSR) is the highest arrival rate that passes the gate on a fresh 4-minute window and whose next tested rung fails the gate. It measures sustained steady-state behavior under continuous arrivals, not short-burst tolerance.
Throughput by workflow shape
| Shape | Max sustainable rate | Observed result |
|---|---|---|
| Noop | 1,500/sec | p50 12ms / p99 26ms |
| Sequential 1x5 | 530/sec | ratio 1.0000, zero drops |
| Sequential 1x25 | 90/sec | ratio 1.0000 |
| Fanout-10 | 280/sec | p50 28ms / p99 66ms |
| Fanout-50 | 75/sec (ceiling not reached) | p50 48ms / p99 112ms |
| Fanout-100 | 55/sec | p50 137ms / p99 426ms at 45/sec |
Fanout-50 at 75/sec is 3,750 activity executions per second with a flat latency tail.
Latency under load
| Sustained rate (sequential 1x5) | p50 | p99 |
|---|---|---|
| 10/sec (warm) | 25ms | 31ms |
| 350/sec | 33ms | 54ms |
| 460/sec | 55ms | 1.4s |
Payload scaling
Sequential 1x5, payload carried as workflow input and every activity result:
| Payload | Rate | Completion ratio | p50 |
|---|---|---|---|
| 128B | 460/sec | 0.9988 | 55ms |
| 1KB | 460/sec | 1.0000 | 70ms |
| 8KB | 300/sec | 1.0000 | 42ms |
Endurance and overload
- A 30-minute soak at 370/sec completes with ratio 0.9998, p50 49ms, no latency drift, and no restarts.
- Under 2x overload (1,060/sec offered against a 530/sec ceiling), the platform sheds excess load at intake, completes all accepted work, drains cleanly with zero restarts, and returns to normal latency immediately. There is no collapse and no recovery period.
Reliability under failure
A fault-injection campaign of ~1.7M workflows ran against the same environment: sidecar kills mid-execution, repeated kills targeting freshly booted replacements, scheduler member kills with leadership churn, and hard PostgreSQL outages.
| Scenario | Result |
|---|---|
| No-fault control at 300/sec | 99.997% completion, p50 34ms / p99 102ms |
| Sidecar kill mid-execution | replacement ready in 6s, no loss |
| Repeated kill into a booting replacement | zero ghost instances, zero duplicate executions |
| Scheduler member kill and leadership churn | full recovery, no lost work |
| PostgreSQL outage (11-25s) | platform survives and reconnects |
| Rolling restart under load | 99.997% completion |
| Durable timers and external events with concurrent kills | 30,000/30,000 delivered, every timer fired, zero timeouts |
Comparison with Dapr open source
The same clusters, storage, node layout, load harness, and measurement gates were rerun against Dapr open source v1.18, deployed with its Helm chart in high-availability mode and a PostgreSQL actor state store tuned identically to Catalyst's: the same volume class, the same server tuning, the same memory budget, and the same dedicated database node. One structural difference favors open source in latency cells: its clients reach the sidecar directly, while the Catalyst numbers include its managed network entry point.
| Benchmark | Catalyst result | Advantage over Dapr OSS |
|---|---|---|
| Noop throughput | 1,500/sec | 1.5x |
| Sequential 1x5 throughput | 530/sec | 1.6x |
| Latency at max sustained rate | p50 79ms | ~5x lower |
| Fanout-10 throughput | 280/sec | 1.6x |
| Deep chain 1x25 throughput | 90/sec | ~1.9x |
| Fanout-50 throughput | 75/sec | 2.5-3x |
| Fanout-100 throughput | 55/sec | 3.4x |
| Warm latency (10/sec) | p50 25ms / p99 31ms | 2x lower |
| p99 latency under 2x overload | 4.4s, no collapse | ~10x lower |
The pattern is mechanistic, not incidental: Catalyst's advantage grows with the number of durable events per workflow, from 1.5x on the event-light noop shape to 3.4x on 100-wide fanouts, because Catalyst eliminates per-event scheduler round trips. Both platforms degrade gracefully under 2x overload and neither loses accepted work; Catalyst's tail latency under overload is roughly ten times lower.
For a feature-level comparison beyond performance, see Dapr OSS vs Catalyst.
