Snowflake vs. Databricks

Snowflake ofrece un SLA de disponibilidad del 99,99 %, por lo que es altamente fiable para los clientes.

Snowflake incluye BCDR como una función estándar y gestionada que ofrece replicación y conmutación por error fluida entre distintas regiones y nubes. En lo que respecta a Databricks, implementar BCDR requiere un esfuerzo significativo por parte del usuario, que puede extenderse durante meses, y aun así no garantizar una preparación completa ante desastres. 

Unity Catalog no es un catálogo totalmente listo para las empresas, ya que le faltan ciertos controles imprescindibles, o aquellos con los que cuenta son insuficientes:

• Carece de una función de continuidad del negocio y recuperación ante desastres sencilla y lista para usar*. 

• Existen lagunas en los controles de acceso detallados de Unity Catalog. 

• Carece de funciones de privacidad avanzadas, como políticas de privacidad diferencial, de agregación y de proyección, a pesar de que estas han sido un estándar en Snowflake Horizon Catalog desde hace años. 

La gestión entre nubes de Unity Catalog es excesivamente compleja, por ejemplo en lo relativo al data sharing y la administración entre distintas nubes y regiones. Por el contrario, estas capacidades constituyen la base de Snowflake Horizon Catalog.

Lo más importante es que Databricks Unity Catalog no es de código abierto ni ofrece una ruta de migración oficialmente documentada a Unity Catalog OSS. De hecho, el propio Unity OSS carece de capacidades sólidas de gobernanza y seguridad (véase el roadmap).

Además, Databricks no proporciona capacidades de ciberdefensa proactiva ni de prevención y recuperación frente a amenazas. En contraste, Snowflake ofrece prevención nativa contra amenazas, como protección frente a IP maliciosas, y copias de seguridad inalterables orientadas al cumplimiento, entre otras capacidades.

Snowflake Data Sharing proporciona un data sharing seguro entre nubes y regiones con políticas y control de acceso basado en roles. Es rentable gracias a capacidades como Egress Cost Optimizer y al programa de descuentos de data sharing. Snowflake admite el uso compartido de modelos de IA y todo tipo de datos listos para la IA, incluidos los datos en formato de tabla abierto como Apache Iceberg y Delta Lake, y activos de IA. Todo esto se encuentra disponible inmediatamente tanto para los clientes de Snowflake como para los que no lo son.

Databricks Delta Sharing puede tener un coste muy elevado. Cuantos más consumidores utilicen Delta Share desde regiones remotas, mayores serán los costes de salida de datos que asuma el proveedor de la nube. Además, Delta Sharing, de código abierto, presenta varias limitaciones en cuanto a la seguridad y gobernanza de los datos, y obliga a los clientes a utilizar el Unity Catalog propietario para habilitar un data sharing realmente eficaz. Por último, actualmente los clientes de Databricks no pueden compartir agentes, vistas de métricas de Unity Catalog ni servicios de búsqueda. Esto añade complejidad de ingeniería que la deben asumir los propios clientes a la hora de preparar los datos para los agentes y la IA.

La filosofía de datos abiertos de Snowflake se basa en un principio claro: “la arquitectura debe pertenecer al cliente, no a su proveedor”. Así lo demuestran nuestras continuas contribuciones a proyectos de código abierto, como Apache Iceberg™, Apache Polaris™, Apache Nifi™ y, más recientemente, Open Semantic Interchange (OSI), que promueve una gobernanza y un desarrollo independientes de los proveedores. De esta forma, los clientes tienen libertad para elegir las mejores herramientas sin miedo a depender del proveedor que las ofrezca.

Por otro lado, la promesa inicial de Databricks gira en torno al código abierto, aunque sus capacidades empresariales esenciales siguen siendo propietarias. Por ejemplo, la versión de código abierto de Unity Catalog (Unity OSS) carece de funciones de seguridad básicas, lo que significa que los clientes deben adoptar el Databricks Unity Catalog propietario para contar con capacidades de seguridad y gobernanza, y su arquitectura pasa a depender del roadmap y las prioridades de Databricks.

Snowflake, que está totalmente gestionado y funciona sin servidor, ayuda a los clientes a ofrecer valor más rápido mediante optimizaciones integradas, como Automatic Clustering y Query Acceleration Service. Asimismo, permite controlar y optimizar los costes de forma transparente con una interfaz de gestión de costes lista para usar, que ofrece una visión completa de todas las cuentas de los clientes, con información detallada sobre gastos, presupuestos y costes. 

Según las pruebas de concepto de clientes y las pruebas de terceros, los costes de Databricks aumentan y el rendimiento se ralentiza a medida que aumentan la complejidad, la simultaneidad y los volúmenes de datos. Databricks también va un paso por detrás en materia de gobernanza de costes nativa, ya que no permite aplicar límites de gasto y ofrece una atribución de costes por consulta limitada y poco integrada.