Si ya tienes datos en Azure y tu equipo piensa en "pipelines" más que en "DAGs", Azure Data Factory te saca del paso más rápido. Si en cambio necesitas orquestar flujos que cruzan varias nubes o dependencias que cambian seguido, Apache Airflow te da ese control, a cambio de que alguien lo mantenga. No hay un ganador absoluto — hay un ajuste a tu stack y a cuánto tiempo quieres gastar en mantenimiento. En Azure Data Factory Desde Cero lo armamos con ADF real, así que vamos a lo concreto.
Qué hace cada uno realmente
Azure Data Factory es un servicio administrado de integración de datos: diseñas los pipelines arrastrando actividades en un canvas visual, conectas más de 90 fuentes nativas (SQL Server, Blob Storage, SFTP, APIs, bases on-premise) y Azure se encarga de ejecutar, escalar y loguear todo. Apache Airflow es open-source: escribes los flujos como código Python —DAGs, grafos acíclicos dirigidos— y decides tú mismo cómo se orquesta cada tarea. Airflow no transforma datos por sí mismo; coordina que otros sistemas (Spark, dbt, un script, una API) hagan el trabajo en el orden correcto.
La diferencia que de verdad te va a importar
- ▸Enfoque: ADF es visual y low-code; Airflow es código Python puro, pensado para equipos que versionan todo en Git.
- ▸Mantenimiento: ADF lo administra Azure de punta a punta; Airflow lo gestionas tú o pagas un servicio administrado (Astronomer, Amazon MWAA).
- ▸Conectores: ADF trae más de 90 integraciones nativas listas para usar; en Airflow dependes de providers y plugins, con más trabajo manual.
- ▸Costo típico: según comparativas públicas de 2026, un pipeline run en ADF cuesta entre 0.25 y 1 dólar; mantener Airflow administrado ronda los 500-2,000 dólares al mes.
- ▸Mejor para: ADF gana en ETL/ELT Azure-native con interfaz visual; Airflow gana en orquestación cross-cloud y lógica de scheduling compleja.
Lo que cambió en 2026: Airflow ya no vive dentro de ADF
Esto es lo que te pierdes si solo lees documentación vieja: desde el 1 de enero de 2026, Microsoft dejó de permitir crear nuevas instancias de Airflow dentro del Workflow Orchestration Manager de Data Factory. Si quieres Airflow administrado en el ecosistema Microsoft, ahora te redirige al job de Apache Airflow dentro de Microsoft Fabric, que desde septiembre de 2026 soporta Airflow 2.10.5. ADF sigue siendo ADF, pero si tu plan era "usar Airflow y que Azure me lo administre", ese camino pasa por Fabric, no por Data Factory.
Cuál conviene según tu caso
- ▸Si la mayoría de tus fuentes son SQL Server, Blob Storage o Dynamics y tu equipo viene de BI/analítica, ADF te ahorra semanas de configuración.
- ▸Si orquestas trabajos que tocan AWS, GCP y on-premise a la vez, o necesitas reintentos y ramificaciones condicionales finas, Airflow (o su versión dentro de Fabric) te da ese control.
- ▸Si el equipo entero piensa en Python y quiere todo versionado, Airflow se siente natural; si prefieren una UI que cualquiera pueda leer, ADF gana.
Lo que nadie te dice en la demo de venta: el canvas visual de ADF es rápido para armar, pero cuando el pipeline crece a 40 o 50 actividades, revisarlo en pantalla se vuelve tan lento como leer código — la ventaja de lo visual se diluye con la escala.
Cómo se ve en la práctica
En el curso de Azure Data Factory Desde Cero armas un Resource Group, creas la Azure SQL Database, el Storage Account y un Data Lake, y los conectas con Linked Services y Datasets hasta levantar tu propio pipeline con triggers — doce sesiones, de cero a un flujo funcionando. Es la base que necesitas antes de meterte con Fabric o con cualquier orquestador más complejo, porque entiendes qué pasa debajo del canvas.
Si en cambio tu stack es AWS o GCP, el patrón ETL es el mismo aunque cambien las herramientas — lo vemos también en los cursos de AWS Data Engineer y GCP Data Engineer.
Si vienes del lado analítico y quieres sumar la pieza de orquestación a tu perfil, la ruta Data Engineer de DataPath te lleva de SQL y Python hasta pipelines en la nube con proyectos reales — Azure Data Factory es una pieza del camino, no la única.
Los errores más comunes al elegir entre los dos
El primero es copiar la decisión de otra empresa sin mirar el propio stack: una fintech que migra a Airflow porque "así lo hace Netflix" pero tiene todo en SQL Server y nadie en el equipo escribe Python termina pagando una curva de aprendizaje que no necesitaba. El segundo es subestimar el mantenimiento de Airflow self-hosted: levantar un clúster propio implica parchear, monitorear colas y resolver que un worker se cayó a las 3 a.m. — por eso la mayoría de equipos que elige Airflow termina pagando un servicio administrado en vez de operarlo ellos mismos. El tercero es forzar todo en ADF cuando el pipeline necesita lógica condicional compleja: se puede, con Switch y If Condition dentro del canvas, pero a partir de cierto punto el flujo se vuelve más difícil de leer que el mismo DAG escrito en código.
Lo híbrido también es una opción real
No es raro encontrar equipos que usan ambos: ADF para mover datos desde sistemas Microsoft hacia un Data Lake, y Airflow (o Fabric) para orquestar la capa de transformación y los modelos que corren después. ADF puede disparar un pipeline externo vía webhook o API, así que la integración no es, en la práctica, un asunto de todo o nada — es decidir qué parte del flujo necesita la robustez de código y cuál se resuelve más rápido con un canvas visual.
