Dagu vs Temporal

Dagu et Temporal résolvent des problèmes différents.

Temporal est un moteur de durable execution pour des workflows applicatifs avec état écrits en code. Dagu est un binaire unique qui planifie et orchestre les commandes que vous lancez déjà. Cette page explique où chacun convient.

Un pipeline planifié en YAML simple
name: nightly-ops
schedule: "0 2 * * *"

steps:
  - id: extract
    run: python scripts/extract.py

  - id: transform
    run: ./bin/transform
    retry_policy:
      limit: 3
    depends: [extract]

  - id: notify
    run: ./scripts/slack-success.sh
    depends: [transform]

Un binaire autonome, sans database ni message broker

Les workflows sont du YAML déclaratif qui appelle des commandes existantes

Executors pour shell, Docker, HTTP, SSH, SQL, sous-workflows et agents IA

Exécution locale, par file d'attente ou distribuée sur des workers

À quoi sert chaque outil

Temporal maintient en vie une logique applicative longue malgré les pannes et les redémarrages. Vous écrivez les workflows en code avec un SDK, et le service rejoue l'event history, donc un worker reprend là où il s'est arrêté. Dagu planifie des jobs et relie des commandes dans un graphe. Il suit les exécutions, les retries, les logs et l'historique sans vous obliger à réécrire les tâches en code dans un framework.

  • Temporal vise les workflows distribués et microservices qui doivent survivre aux pannes.
  • Dagu vise les jobs cron, les pipelines batch et l'automatisation ops construite à partir de commandes.
  • Une étape dans Dagu peut lancer un script, un conteneur, un appel HTTP ou un autre workflow.

Ce que vous exploitez et comment vous écrivez

Temporal exige un service en marche reposant sur Cassandra, PostgreSQL ou MySQL, souvent déployé avec Helm sur Kubernetes ou utilisé via Temporal Cloud. Les workflows vivent dans du code Go, Java, TypeScript ou Python. Dagu est un binaire qui stocke l'état dans des fichiers sur disque. Les workflows sont du YAML lisible dans un diff et committé à côté du code qu'il orchestre.

  • Aucune database, aucun broker ni cluster n'est requis pour lancer Dagu.
  • Les étapes YAML font un shell out vers vos outils existants plutôt que des appels SDK.
  • Vous pouvez commencer sur un portable et ajouter des workers plus tard quand un hôte ne suffit plus.

Quand choisir Temporal

Si votre problème est la durable execution, Temporal est le bon outil et Dagu ne le remplace pas. Les workflows qui gardent un état pendant des heures ou des jours, attendent des signals externes, posent des timers à travers des processus de longue durée et doivent rejouer de façon déterministe après une panne sont exactement ce pour quoi Temporal est conçu. Dagu n'a pas d'équivalent à ce modèle de programmation.

  • Vous avez besoin de workflows définis en code qui survivent au crash d'un processus et reprennent en cours d'exécution.
  • Vous comptez sur des signals, des timers durables ou des child workflows dans la logique applicative.
  • Votre équipe veut un SDK en Go, Java, TypeScript ou Python plutôt que du YAML déclaratif.

Dagu vs Temporal en bref

Dimension
Dagu
Typical alternative
Écriture
YAML déclaratif qui appelle des commandes.
Workflow en code avec un SDK (Go, Java, TypeScript, Python).
Runtime
Binaire unique avec état dans des fichiers.
Un service reposant sur Cassandra, PostgreSQL ou MySQL.
Idéal pour
Jobs planifiés, pipelines et automatisation ops.
Workflows applicatifs et microservices durables et avec état.

FAQ

Practical questions before adopting Dagu

Dagu remplace-t-il Temporal ?

Dans la plupart des cas, non. Temporal est un moteur de durable execution pour des workflows avec état écrits en code, et Dagu n'offre pas ce modèle. Dagu remplace Temporal seulement si vous l'utilisiez pour de simples jobs planifiés ou des pipelines de commandes, où une installation plus légère convient mieux.

Dagu peut-il exécuter des workflows longs ?

Dagu peut exécuter des tâches longues et orchestrer des pipelines à plusieurs étapes, mais il ne conserve pas l'état d'un workflow défini en code à travers le crash d'un processus et ne rejoue pas l'event history. Si une étape doit s'interrompre pendant des jours et reprendre de façon déterministe après une panne, Temporal est le bon choix.

Pourquoi choisir Dagu plutôt que Temporal pour des jobs planifiés ?

Pour des jobs cron et des pipelines bâtis sur des commandes existantes, Dagu n'a besoin ni de database, ni de broker, ni de SDK. Vous installez un binaire, vous écrivez du YAML, et vous obtenez planification, retries, logs, historique et une Web UI, ce qui est plus léger à exploiter qu'un service Temporal.

Start with one workflow.

Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.

Install Dagu