DuckDB vs Snowflake: mismo resultado, 70% menos de costo

Para la mayoría de las empresas medianas, Snowflake es una solución cara a un problema que no tienen. DuckDB + Parquet resuelve lo mismo sin el candado.

Snowflake es una empresa increíble. Tiene una arquitectura brillante, un equipo de ingeniería de primer nivel, y resuelve problemas reales para empresas que manejan decenas de terabytes de datos con cientos de usuarios concurrentes.

El problema es que la mayoría de las empresas que contratan Snowflake no son esas empresas.

El ciclo de Snowflake en empresas medianas

El patrón es predecible:

1. La empresa crece y tiene problemas con los datos
2. Alguien recomienda Snowflake (o Databricks, o BigQuery)
3. Se firma el contrato con entusiasmo
4. Los primeros meses son costosos pero hay expectativa
5. El costo mensual escala más rápido de lo esperado
6. El equipo interno no tiene el expertise para sacarle provecho
7. Se usa el 15% de las funcionalidades, se paga el 100% del costo
8. A los 18 meses, el CFO pregunta por qué se está pagando tanto

No es un problema de Snowflake. Es un problema de fit. Snowflake está diseñado para equipos de datos grandes, con workloads de alta concurrencia y volúmenes que justifican una arquitectura distribuida. Para una empresa de 100 a 500 empleados con 50GB o 500GB de datos analíticos, es un cañón para matar una mosca.

Qué es DuckDB y por qué importa

DuckDB es una base de datos analítica embebida, diseñada para ejecutarse en proceso (sin servidor separado) y optimizada para queries analíticos sobre datos columnares. Es open-source, gratuita, y en los últimos 3 años se convirtió en la herramienta preferida para análisis local y pipelines de datos a mediana escala.

Lo que hace especial a DuckDB:

• Velocidad en queries analíticos: escanea columnas en vez de filas, lo que lo hace entre 10x y 100x más rápido que PostgreSQL para agregaciones sobre millones de registros.
• Sin servidor: no hay que levantar ni mantener infraestructura. Corre como una librería.
• Lee directamente Parquet: sin importar, sin cargar, sin convertir. DuckDB lee archivos Parquet del disco (o de S3) directamente.
• SQL estándar: no hay un dialecto propio. Si sabés SQL, ya sabés DuckDB.

Apache Parquet: el formato que lo cambia todo

Parquet es un formato de almacenamiento columnar open-source desarrollado originalmente para el ecosistema Hadoop. Hoy es el estándar de facto para datos analíticos.

¿Por qué importa?

• Compresión eficiente: un dataset de 10GB en CSV puede pesar 1.5GB en Parquet.
• Queries parciales: si una query solo necesita 3 columnas de una tabla de 50, Parquet lee solo esas 3 columnas. No hay lectura innecesaria.
• Interoperable: Parquet lo leen DuckDB, Spark, Pandas, Arrow, BigQuery, Athena. Nunca quedás atado a una herramienta.
• Versionado fácil: archivos Parquet se pueden versionar en Git o en S3 con un prefijo de fecha.

La combinación DuckDB + Parquet reemplaza a Snowflake para el 95% de los casos de uso de empresas medianas.

Comparación directa

	DuckDB + Parquet	Snowflake
Costo mensual	$0 (open-source) + storage en S3	$500 a $5.000+ según uso
Setup inicial	Horas	Semanas
Mantenimiento	Mínimo	Requiere expertise específico
Vendor lock-in	Ninguno	Alto (Snowflake SQL, Snowpipe, etc.)
Escala máxima práctica	~1-5 TB	Petabytes
Concurrencia	Baja-media (decenas de usuarios)	Alta (miles de usuarios)
Curva de aprendizaje	SQL estándar	SQL + conceptos específicos de Snowflake

Para la mayoría de las empresas medianas, la columna de DuckDB + Parquet es suficiente. La columna de Snowflake empieza a tener sentido cuando superás el terabyte o tenés decenas de usuarios analíticos concurrentes.

Un ejemplo real: el cierre mensual

Un caso típico: empresa de e-commerce con 5 millones de transacciones históricas (~80GB de datos). Su proceso de cierre mensual tardaba 4 días porque implicaba:

• Exportar datos de WooCommerce a CSV
• Importar a Excel
• Cruzar manualmente con datos de logística (otro CSV)
• Cruzar con costos del ERP (tercer CSV)
• Construir el reporte final a mano

Con un stack DuckDB + Parquet + dbt:

• Los datos de las 3 fuentes se ingresan automáticamente cada noche en Parquet
• dbt modela las transformaciones en SQL
• DuckDB ejecuta las queries en segundos
• El reporte de cierre se genera en 2 minutos

Costo de la solución: el tiempo de implementación. Costo mensual recurrente: el storage en S3 (menos de $10/mes para ese volumen).

Cuándo sí tiene sentido Snowflake

Siendo honestos: hay casos donde Snowflake (o Databricks) es la herramienta correcta.

• Tenés más de 5 terabytes de datos analíticos
• Tenés más de 50 usuarios analíticos concurrentes
• Tenés un equipo de datos interno grande que ya conoce el ecosistema
• Necesitás funcionalidades específicas como Snowflake Marketplace o el data sharing entre organizaciones
• Estás en una industria con compliance muy específico que Snowflake ya tiene certificado

Fuera de esos casos, estás pagando por funcionalidades que no usás.

La trampa del vendor lock-in

El problema más sutil de Snowflake no es el costo mensual. Es el lock-in que se acumula con el tiempo.

Snowflake tiene su propio SQL con extensiones propias. Tiene Snowpipe para ingesta. Tiene Streams y Tasks para orquestación. Cuanto más tiempo usás estas funcionalidades, más difícil es migrar.

Con DuckDB + Parquet, los datos viven en archivos estándar en S3. El código de transformación es SQL estándar. Si mañana aparece una herramienta mejor, la migración es casi trivial.

Conclusión

El stack open-source moderno (DuckDB + Parquet + dbt + Dagster) no es una solución de segunda categoría. Es lo que usan equipos de datos sofisticados que entienden que la herramienta correcta es la más simple que resuelve el problema.

Para empresas medianas con hasta 1-5TB de datos analíticos y equipos de datos pequeños, es la elección correcta en casi todos los casos.

El dinero que se ahorra en licencias se puede invertir en hacer las cosas bien desde el inicio.