Play
Databricks vs Snowflake. Un debate interminable, con defensores apasionados de ambos lados. Hace años, cada plataforma apuntaba a un público distinto: Snowflake al analista y al equipo tradicional de BI, y Databricks al data scientist y a los equipos de ML. Hoy las funcionalidades de ambas se acercan cada vez más a la paridad, y las dos atienden prácticamente a todos los perfiles. Pero el debate sigue. "Snowflake es caro", "Databricks es lento" o [inserta aquí la descalificación de turno]: este tipo de pullas abundan en LinkedIn y Reddit, ya sea de fans entusiastas o de empleados de alguna de las compañías.
En SELECT quisimos hacer un benchmark imparcial, repetible y práctico. Buscábamos que estuviera impulsado por software, de modo que un job de Python ejecutara las consultas y registrara los resultados. Lo diseñamos para poder sumar nuevas plataformas con facilidad. Y, para rematar, queríamos una visualización clara encima de todo. Le metimos un montón de esfuerzo (¿quizás demasiado?) para entregarte esta comparación imparcial.
Una aclaración importante antes de empezar: los benchmarks solo te dicen qué tan rápido corrió el benchmark. No simulan workloads de producción ni predicen qué pasará con tus datos y tu SQL. Aunque sí se pueden sacar algunas conclusiones a partir de estos datos, ¡no dejes de experimentar con tus propios datos y patrones de diseño!
El setup
Los datos
Nuestro benchmark usa TCP-H con Scale Factor 1000. Este conjunto de datos tiene cerca de 6 mil millones de filas en la tabla más grande. Tanto Snowflake como Databricks ofrecen datos TPC-H, pero no coinciden en tamaños ni traen exactamente los mismos conjuntos de datos grandes. Para una comparación pareja hay que mover los datos de Snowflake a Databricks vía ETL. Lo más fácil es usar una herramienta pensada para esto, como Estuary, aunque también puedes hacerlo por tu cuenta.
Databricks incluye:
- tpcds_sf1 y sf1000
- tpch con 30 millones de filas. Esto es más o menos la mitad del scale factor 10 de Snowflake, que tiene 60 millones de filas.
Snowflake incluye:
- tpcds_sf10 y 100
- tpch con scale factors 1, 10, 100 y 1000
Como era de esperar, las plataformas no facilitan la comparación de rendimiento al no ofrecer datos de muestra equivalentes. 🤨
Escenarios
Usamos estas consultas estándar bajo 3 escenarios:
- Correr las 22 consultas en forma secuencial. En este escenario, solo la consulta 1 es un cold start y cada consulta siguiente puede aprovechar el caché del warehouse generado por las anteriores.
- Correr las 22 consultas en forma concurrente. Aquí ponemos a prueba la capacidad de la plataforma para ejecutar varias consultas a la vez y observar si hay escalado horizontal.
- 5 consultas en cold start. Corrimos una pequeña selección de consultas, con distinta complejidad y estilo, para ver cómo se comparan las plataformas al ejecutarlas sobre un warehouse frío.
Workloads de CTAS: dado que las consultas estándar del benchmark devuelven resultados más bien pequeños y en su mayoría muy agregados, no representaban bien un workload real de CTAS, porque el payload de escritura quedaba demasiado chico para exigir el throughput de escritura. Para probar operaciones intensivas en escritura, creamos 5 variantes que materializan grandes conjuntos de resultados con distintas formas de datos, desde tablas estrechas con miles de millones de filas hasta tablas muy anchas y desnormalizadas. Así pudimos comparar el rendimiento de escritura con distintas formas de tabla y complejidad de consulta.
Workloads de DML: aquí eliminamos 1 mes de datos de la tabla y los volvemos a insertar. 1 mes equivale a cerca del 1% de los datos, o sea unos 6 millones de filas. Esta prueba evalúa tanto la eficiencia del query pruning (al apuntar a ese mes) como la eficiencia del DML.
Warehouses
Para cada run y escenario se autogenera un nuevo warehouse al inicio, y se destruye apenas termina el trabajo. Así podemos ver el costo total del warehouse de manera aislada y dejar el tiempo en idle fuera de la ecuación.
Un Databricks Serverless SQL Warehouse equivale, a grandes rasgos, a un Snowflake Warehouse de un tamaño mayor. Por ejemplo, un Small en Databricks equivale más o menos a un Medium en Snowflake. Corrimos los 4 escenarios anteriores sobre estas combinaciones de warehouse.
- Snowflake Medium vs Databricks Small
- Snowflake Large vs Databricks Medium
- Snowflake XL vs Databricks Large
Esta comparación de tamaños se respalda con la documentación de Snowflake y Databricks, donde se asume que el Worker Count de Databricks equivale a los Credits de Snowflake.
Atribución de costos
Queríamos que la atribución de costos fuera lo más exacta posible. Para lograrlo se usan warehouses aislados, como se describió arriba. Tomamos los datos reales de facturación (en credits o DBUs) durante la vida útil de ese warehouse. Al final, aplicamos una calculadora de costos flexible para usar distintos costos por credit o por DBU y simular distintos tiers de plataforma. Con este enfoque eliminamos toda la complejidad de atribuir costos a consultas concurrentes, incrementos mínimos de facturación, etc. Simplemente miramos el costo total del escenario.
Cuando mostramos el costo por consulta individual en lugar de por run completo, el costo se atribuye a esa consulta en proporción a su tiempo de ejecución. En esencia, el costo total del run (o de la vida útil del warehouse) se reparte entre las consultas para que los números cuadren.
Comparación de costos
El Databricks Standard Tier está siendo retirado (o probablemente ya se retiró en octubre de 2025). Por eso, al comparar el List Price más bajo de cada plataforma, la comparación sería Snowflake Standard a $2 / credit vs Databricks Enterprise a $0.70 / DBU. Nos parece una comparación justa, porque el tier Standard de Snowflake es una versión completa de Snowflake, en la que la principal función ausente es time travel. Sin embargo, sabemos que muchos lectores van a querer comparar Enterprise vs Enterprise. Por eso mostraremos ambas: Databricks a $0.70 / DBU vs Snowflake a $2 / credit y a $3 / credit.
Historial de ejecuciones y análisis
Los IDs de las consultas y las estadísticas de cada run se registran al instante en un duckdb local. Los datos se almacenan al grano de query ID (además de run ID, warehouse y escenario). Las vistas de reporting agrupan los datos para sacar conclusiones a lo largo de runs completos.
Consultas
Las consultas del benchmark están aquí. (Aunque el SQL parezca estar hard-codeado al scale factor 100x, el nombre de la tabla se reemplaza dinámicamente en tiempo de ejecución con el scale factor definido en tu archivo de configuración. Todas las pruebas se corrieron sobre scale factor 1000x). Organizamos las 22 consultas en categorías según complejidad y cantidad de joins. El desglose detallado de categorías está aquí, pero esta captura ofrece un resumen breve.
Escenario 1: 22 consultas secuenciales
Objetivo y setup
Objetivo: correr consultas en forma secuencial imita lo que vives al estar frente a tu escritorio ejecutando consultas en estas plataformas. Es lo que experimentan los usuarios finales cuando lanzan una consulta SELECT. Esta medición permite comparar consulta por consulta y warehouse por warehouse, en línea con la mayoría de los benchmarks TPC-H.
Setup: el setup es muy simple: corremos las 22 consultas, una a la vez. En todos los escenarios, el warehouse se crea al inicio del run y se destruye apenas termina la última consulta. Los resultados de las consultas se registran al instante en el duckdb.
En este escenario solo la consulta 1 es un verdadero "cold start"; las consultas 2 a 22 se consideran tibias, porque el warehouse queda encendido durante todo el run.
Resultados
Snowflake a $2 / Credit vs Databricks a $0.70 / DBU:
Snowflake a $3 / Credit vs Databricks a $0.70 / DBU:
Se ve que, a $2 / Credit, Snowflake es 34% más rápido y 17% más económico. Si subimos Snowflake a $3 / credit, Databricks queda 20% más económico.
Escenario 2: 22 consultas concurrentes
Objetivo y setup
Objetivo: esto simula cargar un dashboard de BI o correr jobs en los que se disparan decenas de consultas al mismo tiempo. La idea es probar cómo maneja la concurrencia cada plataforma.
Setup: usamos Python para disparar las 22 consultas a la vez y registrar los resultados.
Resultados
Snowflake a $2 / Credit vs Databricks a $0.70 / DBU:
Snowflake a $3 / Credit vs Databricks a $0.70 / DBU:
¡En ambos escenarios Snowflake fue más rápido y más económico! Esto significa que, para workloads concurrentes, Snowflake parece ser el ganador (en este escenario de benchmark).
Pero veamos cómo manejó la concurrencia cada plataforma. Si la concurrencia se gestionara a la perfección (sin queuing ni competencia por recursos), el tiempo total de la prueba concurrente debería parecerse al de la consulta más larga corriendo sola.
| Plataforma | Tamaño de Warehouse | Consulta aislada más larga | Wallclock concurrente | Ratio |
|---|---|---|---|---|
| Databricks | SMALL | 134.5 seg | 369.5 seg | 2.7x |
| Databricks | MEDIUM | 64.5 seg | 296.0 seg | 4.6x |
| Databricks | LARGE | 32.9 seg | 176.5 seg | 5.4x |
| Snowflake | MEDIUM | 94.7 seg | 278.7 seg | 2.9x |
| Snowflake | LARGE | 45.2 seg | 142.8 seg | 3.2x |
| Snowflake | XLARGE | 20.7 seg | 99.7 seg | 4.8x |
Los datos de arriba muestran que en ambas plataformas hay una penalización al correr consultas concurrentes (correr varias a la vez las vuelve más lentas o hay queuing), pero Snowflake tiene mejor ratio en esta comparación.
Al correr 22 consultas concurrentes vemos que Snowflake escaló hasta 4 clusters en Medium y Large, y solo usó 3 clusters en el XL. Por eso el XL costó apenas unos centavos más que el Large.
Lamentablemente, esta misma información no está disponible en Databricks. No encontré la manera de saber cuántos clusters se utilizaron.
Escenario 3: Cold Start
Objetivo y setup
Objetivos: medir los tiempos de ejecución sin "caché del warehouse" y ver si el tiempo de arranque del warehouse impacta en los resultados.
Ambas plataformas aprovechan el "warehouse cache" o la "aceleración Photon", un caché que vive en la VM que ejecuta la consulta. Al correr consultas en forma secuencial, la consulta 2 puede aprovechar parte del caché generado por la consulta 1, y así sucesivamente.
Setup: para ver cómo se comportaban las consultas sin caché disponible, diseñamos un escenario que apaga el warehouse entre cada ejecución. En este caso decidimos no correr las 22 consultas, porque generaría un gasto excesivo.
El tiempo de creación del warehouse no se cuenta en el wall clock total, pero el tiempo de arranque del warehouse SÍ se cuenta en el wall clock total.
Las consultas
| Consulta | Categoría | Complejidad | Descripción |
|---|---|---|---|
| Q1 | Agregación y filtrado simples | Baja (calentamiento) | Múltiples agregaciones (SUM, AVG, COUNT) con GROUP BY sobre una tabla de 600M filas |
| Q3 | Joins básicos (2-4 tablas) | Media (OLAP estándar) | Join de 3 vías con agregación y filtrado por fecha |
| Q5 | Joins complejos (5+ tablas) | Alta (prueba de estrés) | Join de 6 vías con cálculo de ingresos y filtrado geográfico |
| Q10 | Joins básicos (2-4 tablas) | Media (OLAP estándar) | Join de 4 vías con filtro selectivo y GROUP BY de alta cardinalidad |
| Q18 | Subconsultas y semi-joins | Media (OLAP estándar) | Subconsulta IN con filtro de agregación (HAVING) |
Consulta Categoría Complejidad Descripción Q1 Agregación y filtrado simples Baja (calentamiento) Múltiples agregaciones (SUM, AVG, COUNT) con GROUP BY sobre tabla de 600M filas Q3 Joins básicos (2-4 tablas) Media (OLAP estándar) Join de 3 vías con agregación y filtrado por fecha Q5 Joins complejos (5+ tablas) Alta (prueba de estrés) Join de 6 vías con cálculo de ingresos y filtrado geográfico Q10 Joins básicos (2-4 tablas) Media (OLAP estándar) Join de 4 vías con filtro selectivo y GROUP BY de alta cardinalidad Q18 Subconsultas y semi-joins Media (OLAP estándar) Subconsulta IN con filtro de agregación (HAVING)
Resultados
Aquí se ve que Snowflake fue varios órdenes de magnitud más rápido y un poco más económico.
Al mirar el detalle, encontramos que el tiempo de arranque de Databricks fue de unos 7 segundos por arranque, mientras que el de Snowflake fue inferior a un segundo en todos los casos.
Escenario 4: CTAS (Create Table As Select)
Objetivo y setup
Objetivo: el objetivo es medir operaciones intensivas en escritura, típicas de las tareas de data engineering y de los proyectos de dbt. Las consultas estándar de TPC-H están optimizadas para lecturas analíticas: escanean grandes conjuntos de datos, pero devuelven resultados pequeños y agregados (sumas, promedios, listas top-N). Si bien esto pone a prueba la ejecución y la optimización de consultas, no exige el rendimiento de escritura. Quisimos entender cómo se comparan Snowflake y Databricks al escribir miles de millones de filas con distintas formas de datos.
Setup: creamos 5 variantes de CTAS, cada una pensada para probar un patrón de escritura específico:
- Narrow Tall (6B filas × 4 columnas): una proyección simple de la tabla LINEITEM con solo 4 columnas clave (l_orderkey, l_partkey, l_quantity, l_extendedprice). Mide el máximo throughput de filas con el mínimo overhead de columnas.
- Standard Tall (6B filas × 16 columnas): una copia completa de la tabla LINEITEM (SELECT * FROM LINEITEM). Representa un patrón habitual de duplicar o archivar tablas de hechos grandes. (Normalmente usarías Clone para esto, pero hoy no estamos midiendo operaciones de Clone.)
- Medium Wide (1.5B filas × 30 columnas): un join de las tablas ORDERS, CUSTOMER, NATION y REGION. Combina rendimiento de lectura y escritura con una complejidad de JOIN moderada y un esquema más ancho, típico de la desnormalización de esquemas en estrella.
- Very Wide (6B filas × 59 columnas): un join totalmente desnormalizado entre todas las tablas TPC-H (LINEITEM, ORDERS, CUSTOMER, SUPPLIER, PART, PARTSUPP, NATION, REGION). Representa el caso extremo de tablas anchas y pre-unidas, habitual en las capas analíticas.
- Filtered (2B filas × 16 columnas): LINEITEM filtrado a órdenes despachadas después de 1995 (WHERE l_shipdate >= '1995-01-01'). Mide el throughput de escritura para copias parciales de tablas, un patrón común en los pipelines de datos incrementales.
Resultados
Snowflake a $2 / Credit vs Databricks a $0.70 / DBU:
Snowflake a $3 / Credit vs Databricks a $0.70 / DBU:
Snowflake a $2 / Credit vs Databricks a $0.70 / DBU, excluyendo la consulta atípica "Very Wide":
Snowflake a $3 / Credit vs Databricks a $0.70 / DBU, excluyendo la consulta atípica "Very Wide":
Se puede afirmar que, en este escenario de benchmark, Databricks tiene una clara ventaja al crear tablas grandes usando CTAS.
Escenario 5: DML (Data Manipulation Language)
Objetivo y setup
Objetivo: Delete + Insert es un patrón habitual para actualizar datos de forma incremental. Es la manera más efectiva de transformar segmentos puntuales de datos en tablas grandes y, por eso, un escenario importante para probar.
Setup: al inicio del run se crea una copia de los datos fuente del benchmark. Esto no se cuenta en el tiempo del run ni en las métricas de costo. Una vez creada la copia, comienza el proceso del benchmark. Se elimina 1 mes de datos, unos 6M filas, o sea cerca del 1% del total. Después se vuelve a insertar el mismo mes desde la fuente. Esto simula un escenario real de ETL en el que los registros coincidentes se eliminan + insertan. Nota: no usamos merge porque es sabido que delete + insert le saca ventaja a merge.
Resultados
Snowflake a $2 / Credit vs Databricks a $0.70 / DBU:
Snowflake a $3 / Credit vs Databricks a $0.70 / DBU:
Los resultados aquí son muy interesantes. La razón por la que Snowflake M, L y XL procesan los datos en menos de 20 segundos es un excelente query pruning. Los 6 mil millones de filas se podan y se tratan como 6 millones, por lo que la operación corre sobre un conjunto mucho más chico. El warehouse Small de Snowflake tarda más del doble porque sufre spillage tanto en el delete como en el insert.
En Databricks pasa algo parecido. Se observa una concentración entre 35 y 39 segundos en todos los tamaños de warehouse. Databricks reduce de forma efectiva el tamaño del dataset, así que M, L y XL lo manejan sin problema. Solo que no tan rápido como Snowflake.
Cómo reproducir este benchmark
Si quieres correr estas pruebas por tu cuenta, es relativamente fácil. Como dijimos antes, lo primero es hacer ETL del conjunto de datos 1000x desde Snowflake a Databricks. Esta es la parte difícil y la única para la que no proporcionamos automatización, porque hay demasiadas variables en juego. ¡De nuevo, te recomiendo usar Estuary para esto!
Una vez que los datos estén disponibles en tu cuenta de Databricks, puedes seguir la guía de inicio aquí. Solo necesitas tener UV y el Snowflake CLI instalados, configurar tu archivo .env ejecutando uv run setup_config.py, ¡y ya puedes empezar a correr benchmarks! El readme tiene muchos ejemplos de cómo correr escenarios individuales, tamaños de warehouse, o simplemente lanzar todo a full.
Después de correr el benchmark, hay que esperar 2 horas a que se consoliden los datos de facturación. Luego puedes ejecutar uv run enrich.py para enriquecer los resultados con esos datos. Cuando estés listo para visualizarlos, sigues los pasos del readme para hacer eso también.
Conclusiones finales
Los resultados muestran de forma concluyente que Snowflake Standard Edition es la plataforma más costo-efectiva en todos los escenarios, excepto en el de CTAS, donde Databricks supera a Snowflake tanto en costo como en rendimiento. Al pasar a Snowflake Enterprise Edition a $3 / credit, Databricks resulta más económico en algunos escenarios. Insistimos: los benchmarks son solo benchmarks, ¡así que prueba siempre con tus propios datos!
Jeff es consultor de Data y Analytics con más de 15 años de experiencia automatizando insights y usando datos para gobernar procesos de negocio. En lo tecnológico, se especializa en Snowflake + dbt + Tableau. En lo sectorial, tiene experiencia en Servicios Públicos, Ensayos Clínicos, Publicaciones, CPG y Manufactura. Escríbele cuando quieras: [email protected].