Catalyst frente a Soda: comparativa de herramientas de calidad de datos

SodaCL y Soda Core frente a los contratos en el Open Data Contract Standard — puesta en marcha, conectores, detección de anomalías y cuándo cada uno es la elección equivocada.

2026-09-10 · 11 min read

Usa Soda si quieres una CLI de código abierto que ejecute comprobaciones desde un fichero en tu propia infraestructura, si necesitas conectores que Catalyst aún no tiene o si quieres detección de anomalías con machine learning sobre métricas. Usa Catalyst si quieres un producto gestionado sin nada que instalar, con reglas escritas en el navegador por gente que no usa un terminal, y con contratos guardados en ODCS: un estándar abierto en lugar del lenguaje de comprobaciones propio de un proveedor. Ambos son declarativos, ambos empujan las comprobaciones a SQL y ambos son agradables de leer. La diferencia real es que Soda es un runner que operas tú y Catalyst es un servicio que conectas.

Qué es Soda

Soda viene en dos mitades. Soda Core es una CLI de Python de código abierto: la instalas con pip, describes tu fuente de datos en un fichero de configuración, escribes comprobaciones en SodaCL —el Soda Checks Language, un dialecto de YAML— y ejecutas soda scan. Termina con código distinto de cero cuando una comprobación falla, lo que lo hace natural dentro de CI, Airflow o un job de dbt.

Soda Cloud es el SaaS comercial que va encima: dashboards, histórico de comprobaciones, flujo de incidentes, alertas hacia Slack y sistemas de tickets, y detección de anomalías que aprende la forma normal de una métrica en lugar de compararla con un umbral que tuviste que adivinar. Para organizaciones que no pueden dejar que un SaaS llegue directamente al almacén, Soda ofrece un agente autoalojado que se ejecuta dentro de tu red y habla hacia fuera con Soda Cloud, de modo que los escaneos se siguen configurando de forma centralizada.

La lista de conectores de Soda es amplia —los almacenes habituales más Snowflake, Databricks, Athena, Trino, Oracle y otros a día de hoy— y SodaCL es uno de los lenguajes de comprobaciones más legibles de la categoría. Hay que reconocerlo: es lo más parecido a una experiencia de escritura estilo contrato que existe fuera de los contratos propiamente dichos.

Qué es Catalyst

Catalyst es un producto gestionado de calidad de datos, sin CLI y sin librería. Conectas un usuario de base de datos en modo solo lectura, importa el esquema y construyes reglas en el navegador: not-null, unicidad, rangos, patrones, conjuntos de valores permitidos, frescura, integridad referencial y SQL personalizado para lo demás. Las reglas se guardan como contratos del Open Data Contract Standard: el constructor visual y el YAML son dos vistas de un mismo documento, y el YAML es la fuente de verdad, así que un cambio hecho en la interfaz es un diff de una línea.

Las comprobaciones se ejecutan como SQL dentro de tu almacén según una programación. El dataset se queda ahí; Catalyst guarda resultados, recuentos de violaciones y hasta cinco filas de ejemplo que fallan por comprobación, capturadas mientras la comprobación se ejecuta, nunca el dataset en sí. Conectores a día de hoy: PostgreSQL, MySQL, SQL Server, BigQuery, Redshift, Microsoft Fabric, más subida de ficheros CSV, JSON y Excel.

Cara a cara

Puesta en marcha: cómo es la primera hora

La primera hora con Soda Core es una pequeña tarea de ingeniería: crear un entorno de Python, instalar el paquete de tu almacén, escribir un configuration.yml con las credenciales, escribir un checks.yml, ejecutar el escaneo y decidir después qué lo ejecuta de forma programada y dónde van los resultados. Nada es difícil y la documentación es buena. Aun así, ahora es un componente del que eres responsable: un entorno de Python que parchear, credenciales que colocar en un sitio seguro y un planificador que cablear.

Soda Cloud elimina parte de eso, pero si tu postura de seguridad exige el agente autoalojado, has cambiado un pip install por un despliegue de Kubernetes. Ese intercambio es sensato para una organización grande con equipo de plataforma, y malo para un equipo de datos de cinco personas.

La primera hora con Catalyst es configuración: crear un rol de solo lectura, pegar los datos de conexión y elegir una tabla. La importación del esquema lee el catálogo y propone un contrato de base a partir de los tipos y la nulabilidad que encuentra, así que empiezas editando treinta reglas generadas en lugar de tecleándolas. La guía de PostgreSQL tiene los grants exactos; Redshift tiene sus propias particularidades que conviene leer antes.

Escribir las reglas

SodaCL es genuinamente agradable de leer:

checks for orders:
  - missing_count(order_id) = 0
  - duplicate_count(order_id) = 0
  - invalid_count(status) = 0:
      valid values: [pending, paid, shipped, refunded]
  - freshness(created_at) < 24h
  - row_count > 0

El contrato ODCS equivalente es más extenso, y esa extensión compra algo:

apiVersion: v3.0.0
kind: DataContract
info:
  title: orders
  version: 1.0.0
  owner: data-platform
schema:
  - name: orders
    physicalType: table
    properties:
      - name: order_id
        logicalType: string
        required: true
        primaryKey: true
        quality:
          - rule: nullCount
            dimension: completeness
            severity: error
            mustBe: "0"
      - name: status
        logicalType: string
        quality:
          - rule: validValues
            dimension: conformity
            severity: error
            mustBe: "['pending', 'paid', 'shipped', 'refunded']"
      - name: created_at
        logicalType: timestamp
        quality:
          - rule: freshness
            dimension: timeliness
            severity: error
            mustBe: "<= 24h"

Hay tres diferencias que importan. El contrato lleva el esquema además de las comprobaciones, así que describe el dataset en lugar de limitarse a afirmar cosas sobre él. Cada regla lleva una dimensión, de modo que cien reglas se agregan en una matriz de cobertura —_¿estamos cubiertos en actualidad, o solo en completitud?_— en lugar de en una lista plana. Y el formato es un estándar abierto bajo el proyecto Bitol de la Linux Foundation, no el lenguaje de un proveedor, así que las reglas son portables a cualquier runner que lo hable.

En contra: SodaCL es más compacto, y para un ingeniero que escribe comprobaciones en un editor de texto, la concisión es una ventaja real. Si tus reglas solo las van a escribir personas cómodas en un repositorio, la estructura extra de ODCS es un sobrecoste que quizá no quieras.

Detección de anomalías, y ser honestos sobre una carencia

La detección de anomalías de Soda Cloud observa una métrica a lo largo del tiempo y señala las desviaciones respecto al patrón que ha aprendido. Catalyst no tiene esto. Las comprobaciones de Catalyst son reglas deterministas con umbrales que tú fijas: un recuento de filas que debe estar por encima de cero, una ventana de frescura de 24 horas, un rango de valores plausibles.

Cuál quieres depende del fallo que intentas detectar. Las reglas deterministas detectan incumplimientos de una promesa declarada, y nunca saltan porque el martes fuera flojo. La detección de anomalías detecta los fallos para los que nadie pensó en escribir una regla —una caída del 40 % en el recuento de filas que técnicamente está por encima de tu umbral > 0— y te cuesta un periodo de ajuste y algunos falsos positivos mientras aprende. Si lo que más te preocupa son los imprevistos de volumen y distribución, esa es una razón genuina para elegir Soda.

Elige Soda si…

• Quieres un runner de código abierto que controles tú. Soda Core tiene licencia Apache y es gratuito; las comprobaciones se ejecutan enteramente dentro de tu infraestructura, sin ningún proveedor por medio.
• Necesitas un almacén que Catalyst aún no soporta: Snowflake, Databricks, Athena, Trino y Oracle son los casos obvios.
• La validación debe hacer fallar un pipeline. soda scan devuelve un código de salida distinto de cero, que es exactamente lo que quiere un job de CI o una tarea de Airflow. Catalyst monitoriza según su propia programación; no bloquea tu build.
• Quieres detección de anomalías, no solo reglas de umbral.
• Vuestra política prohíbe que un SaaS llegue a vuestro almacén. El agente autoalojado mantiene la conexión dentro de tu red. Catalyst está alojado en la UE y solo guarda resultados, recuentos de violaciones y hasta cinco filas de ejemplo que fallan por comprobación, pero la conexión sigue siendo entrante desde un servicio.
• Tus comprobaciones viven junto a tu proyecto dbt y quieres que estén versionadas, revisadas y ejecutadas en el mismo job que los modelos que cubren.
• Tu equipo ya conoce SodaCL. La familiaridad vale más que un formato marginalmente mejor.

Elige Catalyst si…

• Quienes conocen las reglas de negocio no usan un terminal. Un analista o un responsable de dominio puede añadir una regla sin una pull request, sin un entorno de Python y sin una revisión de código del equipo de plataforma.
• Quieres las reglas en un estándar abierto. Los contratos ODCS se exportan como fichero y se importan en cualquier cosa que hable la especificación. SodaCL es legible, pero es de Soda.
• Quieres que todo sea un solo producto. La programación, el histórico, la cobertura y el detalle vienen configurados en lugar de ensamblados a partir de una CLI más una cuenta en la nube más un agente más un orquestador.
• La gobernanza forma parte del requisito. El RBAC, un registro de auditoría y el SSO están en el producto desde el primer día.
• Quieres ver las filas que fallan. Una comprobación fallida enlaza directamente con una muestra de los registros infractores, que suele ser lo primero que pide todo el mundo.
• Quieres precios pequeños y predecibles. Starter es gratuito para una conexión y un dataset (PostgreSQL y MySQL); Team cuesta 29 € por usuario y mes.

¿Pueden coexistir?

Sí, y el reparto es limpio. Soda en el pipeline, como puerta: aserciones rápidas que detienen una carga defectuosa antes de que aterrice, ejecutadas por el mismo job que construyó la tabla. Catalyst por encima del pipeline, como capa de contratos y monitorización: las promesas duraderas sobre los datasets de los que dependen tus consumidores, versionadas como ODCS, comprobadas según una programación con independencia de qué pipeline las escribió hoy, con el histórico de ejecuciones y la vista de cobertura que quiere quien necesita confiar en las cifras, en lugar de un log de job.

Migrar de SodaCL a ODCS es manual a día de hoy —no hay importador—, pero las comprobaciones comunes se corresponden casi uno a uno (missing_count con nullCount, duplicate_count con duplicateCount, invalid_count con valores válidos con validValues, freshness con freshness), e importar primero el esquema genera la mayor parte del contrato antes de que traduzcas nada. Si todavía estás decidiendo qué comprobar siquiera, empieza por la guía para validar datos.

Preguntas frecuentes

¿Soda es gratuito?

Soda Core, la CLI de código abierto, es gratuita bajo licencia Apache 2.0 y puedes ejecutarla en producción sin pagar a nadie. Soda Cloud —los dashboards gestionados, las alertas, el flujo de incidentes y la detección de anomalías— es un producto comercial con sus propios precios; consulta la web de Soda para ver las condiciones vigentes. La mayor parte de lo que la gente imagina cuando dice «Soda» es la mitad en la nube.

¿Catalyst requiere Python o una CLI?

No. Catalyst es una aplicación web. Conectas un usuario de base de datos en modo solo lectura, las reglas se construyen en el navegador o se escriben como YAML de ODCS en el editor, y las ejecuciones se programan en el producto. No hay nada que instalar, ningún entorno que mantener y ningún comando de escaneo que programar.

¿Cuál es la diferencia entre SodaCL y ODCS?

SodaCL es el lenguaje de comprobaciones propio de Soda: compacto, legible y entendido por los runners de Soda. ODCS es el Open Data Contract Standard, una especificación abierta desarrollada dentro del proyecto Bitol de la Linux Foundation que describe el esquema, la propiedad, los niveles de servicio y las reglas de calidad de un dataset en un único documento YAML versionado, y que puede ejecutar cualquier herramienta compatible. La diferencia práctica es la portabilidad: un contrato ODCS sobrevive a un cambio de proveedor.

¿Catalyst hace detección de anomalías?

A día de hoy, no. Catalyst ejecuta reglas deterministas contra umbrales que tú defines, registra el histórico pass/warn/fail y muestra tendencias a lo largo del tiempo. Si necesitas específicamente monitorización estadística que aprenda el rango normal de una métrica, Soda Cloud la tiene y Catalyst no.

¿Puedo usar Soda y Catalyst juntos?

Sí. Una combinación habitual es Soda Core como puerta de build dentro del pipeline y Catalyst como capa de contratos y monitorización sobre las tablas que aterrizan, de modo que los fallos del pipeline detienen pronto los datos malos mientras los contratos dan a los consumidores una promesa versionada y revisable con su propia programación e histórico de ejecuciones.