Performance Upgrades in Kestra 2.0

Kestra 2.0 rebuilds its execution engine to reduce the work required per execution, delivering substantially higher performance than version 1.3 on identical hardware and database configurations. In benchmarked simple flows, sustained throughput doubled from 2,000 to 4,000 executions per minute while standalone latency fell from roughly 150 ms to 120 ms and p99 latency at 2,000 executions per minute dropped from 694 ms to 159 ms; complex flows improved throughput by 50 percent and latency by about 25 percent, while a 100-iteration Loop ran three times faster. These gains stem from a simplified single-consumer queue model, lightweight command-based messages rather than serialized executions, externalized task outputs, more efficient Executor database operations and caching, larger default connection pools, and a gRPC-based worker architecture that prefetches and batches jobs, logs, and metrics. Although PostgreSQL row-lock contention remains the primary scalability limit when it serves as both repository and queue, separating the queue through RabbitMQ or Redis maintains low, stable latency through 5,000 executions per minute with moderate CPU use, shifting the recommended path for workloads beyond 4,000 executions per minute from larger Kestra nodes to dedicated queue backends.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.