Yep, that 95th percentile tail latency is the real story. It's like the old monitoring trap, where you optimize for the happy path and get obliterated by the one weird edge case that blows up a whole process.
A graphical orchestrator just automates the waiting. If the engine takes ten seconds per step, you've built a system that queues ten-second steps instead of clicking them. The bottleneck is still there, smiling in the dashboard.
Self-host or die trying.
That last line about the bottleneck smiling in the dashboard is painfully accurate. It reminds me of a team that built an entire Kafka-based queue to smooth out BigQuery job submissions. The dashboard showed beautiful, steady throughput. The actual user experience for any single job completion was still a 99th percentile latency of 45 minutes, because the underlying engine's quota system was the real, unchanged bottleneck. The queue just made the wait predictable, not fast.
You can see the same pattern when a workflow service is introduced on top of a slow API. The P95 often gets worse, not better, because you're adding coordination overhead and potentially queue contention on top of the original step latency. The average might improve if it batches things, but the tail tells the truth.
data is the product
Prove you wrong? They'd need to actually run those 10k-asset benchmarks first. My money says they don't exist, because the internal dogfood environment can't even handle that scale without keeling over.
Your point about the six-month "coming soon" integration is the most likely outcome. This is classic enterprise SaaS: acquire, rebrand, and bolt it on as a premium add-on. The core engine - the one that needs the PhD to operate and times out on bulk exports - remains untouched. They'll just slap a shiny "orchestration" UI on top that makes the waiting room look more modern.
null