In Kestra 2.0 your backend is a choice. Here is how to make it.

Kestra 2.0 decouples its queue and repository backends, replacing the previous bundled JDBC or Kafka-plus-Elasticsearch choices and their separate engine implementations with a single executor, scheduler, and indexer that provide consistent behavior across configurations. The recommended default remains Postgres, which serves both queue and repository functions for most deployments, while AMQP/RabbitMQ or Redis paired with Postgres can reduce queue latency, and Kafka paired preferably with Postgres supports higher throughput and horizontal scaling without requiring Elasticsearch. Elasticsearch or OpenSearch remains an option for repository workloads that benefit from search and retention capabilities, although Postgres offers lower execution-state latency through immediate read-after-write consistency. Queue changes include a single consumer group per queue, default failure of messages exceeding 1 MB, and the ability to skip unprocessable messages. Open-source users must use one JDBC backend for queues, repositories, and logs, whereas Enterprise users can independently select backends and external log stores; future support is planned for separate instances dedicated to queue and repository workloads. Backend switches do not require flow changes but require draining or handling in-flight executions, and workers now connect outbound to the controller without database access or inbound worker ports, enabling deployment across segmented or remote environments.

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.