Orquestadores de workflows
Elige según el trabajo que necesitas repetir de forma segura.
Una carga nocturna del warehouse, un producto de datos particionado y un entrenamiento en contenedores requieren coordinaciones distintas. Elegiría primero el modelo de ejecución y después compararía programación, recuperación y la edición que el equipo puede operar.
Fuentes revisadas: 2026-09-06. Esta evaluación se basa en repositorios y documentación oficiales. Las preselecciones son mi interpretación; no ejecuté un benchmark de rendimiento ni pruebas de recuperación en producción para este artículo.
Comparación de un vistazo
Los enlaces fijan las versiones del código revisado. Las licencias describen el núcleo; los servicios gestionados, funciones enterprise y binarios distribuidos pueden tener condiciones distintas.
Calificación (1–5): una nota editorial de preparación para el encaje indicado en su fila, con fecha 2026-09-06. Suma cinco criterios de 0, 0,5 o 1 punto: mantenimiento, edición abierta (lo que incluye la edición open source sin nivel de pago), madurez y comunidad, alcance operativo e interoperabilidad, con topes para proyectos archivados, estancados o sin versión estable. El desglose está bajo la tabla y el método en el índice del Blog. Una calificación no es un benchmark ni un ranking universal; las secciones por carga siguen decidiendo.
| Proyecto | Calificación | Licencia del núcleo | Lo preseleccionaría para | Restricción principal |
|---|---|---|---|---|
| Airflow 3.3.1 | Apache-2.0 | Flujos de datos programados con dependencias explícitas entre tareas | Scheduler, base de metadatos e infraestructura de ejecución requieren actualizaciones coordinadas. | |
| Dagster 1.13.21 | Apache-2.0 | Activos de datos cuyas dependencias y materializaciones importan | Adoptar el modelo de activos requiere ingeniería, además de cambiar el scheduler. | |
| Prefect 3.8.5 | Apache-2.0 | Workflows Python con su flujo de control habitual | Los despliegues de producción necesitan servidor y plan de ejecución y recuperación. | |
| Kestra 1.3.37 | Apache-2.0 | Flujos declarativos que conectan scripts, servicios y eventos | Plugins, metadatos y almacenamiento interno forman parte de la operación. | |
| Argo Workflows 4.1.2 | Apache-2.0 | Pasos en contenedores sobre una plataforma Kubernetes existente | La elección incluye operar Kubernetes y el almacenamiento de artefactos. | |
| Windmill 1.804.0 | Compilación AGPLv3; excepciones | Scripts, automatización interna e interfaces para operadores | Los binarios Community Edition incluyen código propietario y condiciones adicionales. |
Cómo se calculó cada calificación
Cinco criterios de 0, 0,5 o 1 punto. Topes: upstream archivado 1, sin versión estable en 18 meses 2, sin versión de disponibilidad general 2,5. "Edición abierta" puntúa lo que incluye la edición open source sin nivel de pago. Puntuado el 2026-09-06 con el repositorio, las versiones y la documentación oficiales; el método está en el índice del Blog.
| Proyecto | Mantenimiento | Edición abierta | Madurez | Operación | Interoperabilidad | Calificación |
|---|---|---|---|---|---|---|
| Airflow | 1 | 1 | 1 | 0,5 | 1 | 4,5 |
| Dagster | 1 | 0,5 | 1 | 0,5 | 1 | 4 |
| Prefect | 1 | 0,5 | 1 | 0,5 | 0,5 | 3,5 |
| Kestra | 1 | 0,5 | 1 | 0,5 | 0,5 | 3,5 |
| Argo Workflows | 1 | 1 | 1 | 0,5 | 1 | 4,5 |
| Windmill | 1 | 0,5 | 0,5 | 0,5 | 0,5 | 3 |
| Temporal | 1 | 1 | 1 | 0,5 | 0,5 | 4 |
AGPLv3 es una licencia open source. Forma parte de la comparación junto con las licencias permisivas. Una descarga gratuita no demuestra que la distribución sea open source; más abajo detallo el caso de Windmill.
Empieza por la carga
- Una instalación Airflow existente: mantendría Airflow entre las opciones cuando sus integraciones y el conocimiento operativo ya resuelven el problema. Exigiría una mejora concreta en recuperación o esfuerzo de desarrollo antes de migrar todos los DAG.
- Un warehouse organizado alrededor de tablas y modelos: empezaría con Dagster cuando los operadores necesitan entender qué datos existen, sus dependencias y qué particiones reconstruir. Compararía Airflow cuando las tareas representan mejor la responsabilidad operativa.
- Una aplicación Python que pasa a ser un pipeline gestionado: empezaría con Prefect. Mantendría la composición habitual de Python y definiría despliegues, estado de tareas, persistencia de resultados y cancelación.
- Varios lenguajes y automatización por eventos: compararía los flujos declarativos de Kestra con el enfoque de scripts de Windmill. Verificaría la edición exacta para identidad, auditoría y requisitos de despliegue.
- Una plataforma basada en Kubernetes: compararía Argo Workflows cuando cada paso encaja naturalmente en un contenedor. Incluiría arranque de pods, cuotas, cuentas de servicio y retención de artefactos en la evaluación.
Son preselecciones, no fronteras excluyentes de funcionalidades. Airflow también admite activos y Dagster también ofrece jobs y ops. La distinción está en el modelo que haría central en la práctica operativa del equipo.
Versiones y notas operativas
Airflow — responsabilidades del plano de control y las tareas
La arquitectura de Airflow separa programación, procesamiento de DAG, servidor API, metadatos y ejecución de tareas. El executor cambia dónde corre el trabajo; los demás componentes siguen necesitando responsables.
Ensayaría el fallo de una tarea cuya escritura externa ya se completó. Comprobaría el destino, además del estado verde del DAG. Limitaría los backfills simultáneos para que reconstruir datos antiguos no bloquee las ejecuciones actuales. Fijaría los paquetes de providers junto con la versión de Airflow.
Dagster — modelar los datos que deben existir
Los activos describen objetos persistidos y el código que los produce. Así, dependencias y materializaciones son unidades relevantes para la plataforma de datos.
Probaría una reconstrucción parcial tras cambiar la lógica de origen: qué particiones se ejecutan, qué salidas se reemplazan y qué controles bloquean el trabajo dependiente. Presupuestaría la adopción del modelo. Distinguiría las capacidades OSS de las marcadas como Dagster+.
Prefect — el flujo Python necesita contratos operativos
Los flows envuelven funciones Python con estado registrado, parámetros, reintentos y capacidades de despliegue. Es útil cuando la composición y las bifurcaciones ya están expresadas en Python.
Probaría la desaparición de un worker, la cancelación y un despliegue con una versión incorrecta del código. Definiría dónde sobreviven resultados y logs al proceso. Una función local exitosa no prueba el servidor ni la infraestructura de las ejecuciones programadas en producción.
Kestra — incluir plugins y almacenamiento
La referencia de arquitectura distingue backends JDBC y Kafka, componentes de ejecución y almacenamiento interno. Hay que ajustarlos a la edición OSS o enterprise elegida. Kestra 2.0, con motor reescrito, está en release candidate y su lanzamiento está previsto para el 2026-09-08; 1.3.37 sigue siendo la línea estable revisada aquí.
Versionaría juntos definición del flujo y plugins, y restauraría tanto los metadatos como los artefactos referenciados. Ensayaría un evento duplicado, un secreto ausente y una actualización de plugin que cambie la estructura de salida.
Argo Workflows — el clúster forma parte del producto
Argo Workflows representa workflows de contenedores como recursos Kubernetes, con pasos o dependencias DAG. Es un proyecto separado de Argo CD y su reconciliación de despliegues.
Probaría la expulsión de un pod, una cuota de namespace agotada y un bucket de artefactos inaccesible. Mantendría los datasets grandes fuera de los metadatos del workflow. Reiniciar el controlador, conservar los artefactos y reintentar la aplicación son problemas distintos.
Windmill — revisar la licencia del artefacto
El LICENSE revisado establece AGPLv3 para la compilación sin enterprise, con áreas de clientes bajo Apache. Las imágenes y binarios Community Edition publicados también incorporan código propietario y restricciones adicionales. Esos artefactos tienen un alcance de licencia distinto.
La introducción del producto describe scripts, flujos y aplicaciones. Lo evaluaría para automatización con interfaces para operadores, incluyendo aislamiento de workers y gestión de secretos en la prueba.
Dónde encaja Temporal
Temporal Server 1.31.2 utiliza la licencia MIT. Su modelo de ejecución durable y replay aborda procesos de aplicación que deben continuar tras un fallo. Lo evaluaría para un proceso de pedidos o aprovisionamiento de larga duración, con temporizadores e interacciones externas.
Esto cambia la comparación: el código del workflow debe respetar las restricciones de replay y las actividades necesitan reintentos seguros. Un proceso de negocio reanudable y un catálogo de activos de datos resuelven problemas operativos distintos. Define cuál necesitas antes de tratar Temporal como reemplazo de Airflow.
Una prueba que pueda cambiar la decisión
Usa un pipeline representativo: ingerir archivos, validar una partición, cargar una tabla analítica y actualizar un índice de búsqueda. Fija la versión del código y la instantánea de entrada; registra estos resultados para cada candidato:
- Repetibilidad: ejecuta dos veces la misma partición y cuenta los efectos externos. Define un contrato de idempotencia para las escrituras.
- Recuperación: termina un worker después de escribir y antes de registrar la finalización. Restaura la base de control y localiza la salida que sobrevivió.
- Aislamiento de backfills: reconstruye un periodo antiguo mientras continúan las ejecuciones actuales. Mide espera en cola y contención por recursos por separado.
- Cambios seguros: despliega una nueva versión con ejecuciones antiguas en curso; ensaya reversión, rotación de credenciales y cancelación.
- Coste operativo: registra servicios en reposo, almacenamiento, arranque de workers, mantenimiento y tiempo para diagnosticar un fallo.
Fija umbrales aceptables antes del ensayo. Un scheduler puede lanzar trabajo que incumpla todos los objetivos de frescura; define el SLO sobre la salida utilizable.
Completa el recorrido de los datos
Combina el orquestador con el almacenamiento de objetos, motor OLAP y sistema de búsqueda vectorial adecuados. El Failure Lab ilustra reintentos acotados y backoff localmente; es un modelo educativo, no un benchmark de estos proyectos.
Compara herramientas de transformación para cambios de modelos y backfills, y observabilidad para detectar fallos y salidas desactualizadas a lo largo del pipeline.