Vendor lock-in: el costo oculto que nadie calcula

El costo real del lock-in en datos no es la licencia, es lo que pagas para salir. Analizamos los cuatro tipos de dependencia y cómo evitarlos.

Hay una conversación que se repite mucho en empresas que llevan 2 o 3 años con Snowflake, Databricks o cualquier otra plataforma de datos enterprise:

“Queremos evaluar alternativas, pero… ya tenemos todo ahí.”

Ese “ya tenemos todo ahí” es el vendor lock-in en acción. Y el problema no es la plataforma en sí — es que el costo de salida crece cada mes que la empresa sigue usando el sistema. Silenciosamente, sin que nadie lo calcule explícitamente.

¿Qué es el vendor lock-in en datos?

El vendor lock-in ocurre cuando los costos de migrar a una alternativa superan los costos de quedarse, aunque la alternativa sea objetivamente mejor o más económica.

En datos, esto sucede en cuatro dimensiones que se acumulan de forma independiente:

1. Lock-in de formato

Los datos están almacenados en el formato propietario del proveedor. No hay un botón de “exportar todo”. Para sacar los datos hay que escribir jobs de extracción, validar que la extracción sea completa, y transformar los datos a un formato que la nueva plataforma entienda.

Snowflake, por ejemplo, almacena datos en columnas internamente, pero la exportación masiva requiere tiempo, recursos computacionales, y en algunos casos costo adicional dependiendo del plan. Para una empresa con 3 años de datos acumulados, exportar puede tomar semanas.

2. Lock-in de funcionalidades

Cuanto más tiempo usas las funcionalidades propietarias, más difícil es migrar.

Snowpipe (ingesta nativa de Snowflake), Streams (captura de cambios), Tasks (orquestación interna), Snowflake Marketplace, Data Sharing nativo — cada funcionalidad propietaria que usas es un punto más de dependencia. Migrar no es solo mover datos: es reemplazar toda la funcionalidad que construiste usando las herramientas del proveedor.

Esto es lo más costoso y lo que menos se anticipa al firmar el contrato inicial.

3. Lock-in de expertise

Tu equipo aprendió a usar el sistema del proveedor. Conocen el dialecto SQL específico, los workflows internos, las mejores prácticas de esa plataforma. Ese conocimiento no es directamente transferible. Si migras, hay un período de productividad reducida mientras el equipo aprende la nueva plataforma.

Para una empresa que no tiene un equipo de datos grande, este costo puede ser prohibitivo en términos de tiempo y momentum.

4. Lock-in de integración

Los dashboards, reportes, y herramientas de BI están conectados al sistema del proveedor. La cadena de extracción, transformación y carga fue diseñada para ese sistema específico. Migrar significa rehacer todas esas conexiones — no solo mover datos, sino reconectar cada punto de consumo.

¿Cómo se acumula el costo a lo largo del tiempo?

El día que firmas el contrato con Snowflake, el costo de salida es bajo: apenas empezaste. Pero cada mes que pasa, el costo de salida sube de forma compuesta:

• Los datos acumulados crecen (más volumen para exportar)
• Más funcionalidades propietarias en producción
• El equipo se especializa más en esa plataforma específica
• Más integraciones y dashboards conectados
• Más queries históricas escritas en el dialecto propietario

A los 3 años, migrar puede costar más que 12 meses de licencia de la nueva plataforma. Y esa ecuación hace que la decisión de quedarse, aunque la plataforma sea cara, se vuelva “lógica” desde el punto de vista económico de corto plazo.

Eso es el lock-in.

Comparación de riesgo de lock-in por plataforma

Plataforma	Lock-in de formato	Lock-in funcional	Costo migración (~3 años)
Snowflake	Alto (formato interno)	Alto (Snowpipe, Streams, SQL propio)	8-20 semanas
Databricks	Medio (Delta Lake es semi-abierto)	Alto (Unity Catalog, Photon)	10-24 semanas
BigQuery	Medio (exportación a Parquet disponible)	Medio (BQML, Dataflow)	6-14 semanas
Redshift	Alto (formato propietario)	Medio-alto	8-16 semanas
DuckDB + Parquet	Ninguno (Parquet es estándar abierto)	Ninguno (SQL estándar)	1-2 semanas
dbt + Dagster	N/A (no almacenan datos)	Bajo (code-first, Git)	1-3 semanas

¿Cómo auditar el lock-in que ya tienes?

Si estás en una plataforma enterprise y quieres entender tu nivel de exposición, hay cuatro preguntas concretas que responder:

1. ¿Cuánto tiempo llevaría exportar todos tus datos a Parquet hoy? Si la respuesta es “no lo sé” o “semanas”, tienes lock-in de formato significativo. Prueba exportar una tabla de 50GB. Si el proceso es complicado o costoso, eso escala linealmente con el resto de tus datos.

2. ¿Qué funcionalidades propietarias usas en producción? Haz una lista de los pipelines y transformaciones que dependen de herramientas específicas del proveedor. Cada uno es un componente que habría que reescribir en una migración.

3. ¿Cuántos de tus data engineers saben SQL estándar vs SQL del proveedor? Si el equipo solo puede escribir queries en el dialecto de Snowflake o BigQuery, la curva de aprendizaje de una migración es más alta. Herramientas basadas en SQL estándar (dbt, DuckDB) tienen una comunidad mucho más grande y conocimiento más portable.

4. ¿Cuántos dashboards y conexiones de BI tienes activas? Cada conexión que apunta a la plataforma actual es un punto de reconexión en una migración. Con 5 dashboards es trabajo de un día. Con 40 dashboards es trabajo de semanas.

El costo de salida en números reales

Una empresa de SaaS B2B implementó Snowflake hace dos años para su infraestructura de datos. El costo mensual empezó en $800/mes. Hoy está en $3.200/mes, principalmente por el crecimiento del volumen de datos y el uso de compute para las queries.

Cuando evaluaron alternativas (DuckDB + Parquet + dbt), la estimación de costo mensual para el mismo workload fue de $80-120/mes en storage S3 más tiempo de ingeniería para migración.

El ahorro anual sería de aproximadamente $36.000. Pero la migración fue estimada en 8-12 semanas de trabajo de ingeniería, con riesgo de interrupciones en los reportes durante el proceso. Y los dashboards de Power BI conectados a Snowflake necesitarían ser reconectados.

El costo de la migración (8-12 semanas de un data engineer a ~$80-100/hora) es de $25.000-$50.000 dependiendo del alcance. El break-even está en el primer año. Pero el equipo eligió quedarse en Snowflake por el riesgo percibido del proceso de transición.

Eso es el lock-in funcionando exactamente como está diseñado: hace que quedarse parezca la decisión lógica, incluso cuando los números dicen otra cosa.

¿Por qué el open-source cambia la ecuación desde el inicio?

La propuesta del stack open-source no es solo el costo cero de licencias. Es la ausencia estructural de lock-in.

Cuando los datos están almacenados en Apache Parquet (un formato estándar que leen DuckDB, Spark, BigQuery, Athena, Pandas y cualquier otra herramienta), el costo de migrar se reduce drásticamente. Los datos ya están en un formato que cualquier herramienta entiende.

Cuando las transformaciones están escritas en dbt con SQL estándar, versionadas en Git, el conocimiento vive en el código —no en la interfaz propietaria de una plataforma. Si mañana aparece una herramienta mejor, el código SQL sigue funcionando.

Cuando la orquestación está en Dagster o Airflow (open-source), el sistema de scheduling no depende del proveedor de datos. Cambiar el motor de consulta no implica reescribir los pipelines.

El stack open-source no es un compromiso técnico. Es una decisión de soberanía sobre tus datos.

¿Cuándo el lock-in enterprise es aceptable?

Siendo honestos: hay casos donde el lock-in en plataformas enterprise tiene sentido.

• Cuando el volumen de datos es tan grande que las ventajas de escala de Snowflake o Databricks compensan el costo y el lock-in
• Cuando las funcionalidades propietarias (como el Data Sharing de Snowflake) son parte central del modelo de negocio
• Cuando la empresa tiene un equipo de datos suficientemente grande para extraer valor real de la plataforma
• Cuando el compliance específico de la industria requiere certificaciones que solo tienen los vendors enterprise
• Cuando no hay capacidad técnica interna para gestionar infraestructura open-source

Fuera de esos casos, el lock-in es un costo que se acumula sin retorno equivalente.

La alternativa desde el inicio

La mejor manera de evitar el lock-in es no crearlo desde el principio.

Un stack open-source bien diseñado desde el inicio tiene el mismo costo de migración en el año 1 que en el año 5: bajo. Los datos están en Parquet, el código en SQL estándar en Git, la orquestación en herramientas portables.

Si en 3 años aparece algo mejor que DuckDB, la migración toma días, no meses. Eso es lo que significa que tus datos te pertenecen de verdad.

Puedes ver la comparación técnica detallada en DuckDB vs Snowflake: costo y performance.

Preguntas frecuentes

¿El lock-in aplica también a herramientas de BI como Tableau o Power BI?

Sí, aunque en menor medida. Las herramientas de BI tienen sus propios formatos de reporte que no son compatibles entre sí, y migrar dashboards entre herramientas implica rehacerlos. La diferencia es que el lock-in de BI suele ser de visualización y presentación, mientras que el lock-in de plataforma de datos afecta al almacenamiento, el procesamiento y la gobernanza —capas mucho más costosas de migrar.

¿Es posible usar Parquet como formato de almacenamiento dentro de Snowflake?

No directamente. Snowflake almacena los datos en su formato interno optimizado. Puedes exportar tablas a Parquet en cualquier momento, pero los datos que están “en” Snowflake están en el formato propietario de Snowflake. Por eso la exportación tiene un costo real en tiempo y recursos cuando el volumen es grande.

¿Qué pasa si contrato DuckDB a través de MotherDuck — tengo lock-in?

MotherDuck ofrece DuckDB como servicio administrado. El lock-in es significativamente menor que con Snowflake porque los datos siguen siendo archivos Parquet estándar y el SQL que funciona en MotherDuck funciona en DuckDB local sin modificación. Si decides salir de MotherDuck, el costo de migración es bajo comparado con cualquier warehouse propietario.

¿Cuánto tiempo lleva implementar un stack sin lock-in desde cero?

Para una empresa mediana con 2-5 fuentes de datos y requerimientos analíticos típicos (reportes de negocio, cierre mensual, dashboards), la implementación de un stack DuckDB + Parquet + dbt completo toma entre 2 y 4 semanas. Para eso es necesario tener claridad sobre qué preguntas se quieren responder con los datos.

¿El equipo de negocio puede trabajar con datos en Parquet sin saber programar?

No directamente. El equipo de negocio interactúa con la capa de presentación: dashboards en Metabase, Power BI o Tableau que conectan al Lakehouse. La infraestructura (Parquet, DuckDB, dbt) la gestiona el equipo técnico. Lo que cambia es que el equipo de negocio tiene acceso a datos confiables, actualizados y consistentes, sin depender de que alguien arme una planilla de Excel manualmente.

---

Si estás evaluando plataformas de datos y quieres entender las diferencias de arquitectura, lee también qué arquitectura necesita tu empresa: Data Warehouse, Data Lake o Lakehouse.

Si estás evaluando cuánto lock-in tienes acumulado, agenda una llamada. Te decimos exactamente cuánto te costaría salir hoy y en 3 años.