Vendor lock-in: el costo oculto que nadie calcula

El costo real del lock-in en datos no es la licencia, es lo que pagás 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.

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:

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 time, recursos, y a veces costo adicional dependiendo del plan.

2. Lock-in de funcionalidades

Cuanto más tiempo usás 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 usás 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.

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 transferible. Si migrás, hay un período de productividad cero mientras el equipo aprende la nueva plataforma.

Para una empresa que no tiene un equipo de datos grande, este costo puede ser prohibitivo.

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 (ETL) fue diseñada para ese sistema específico. Migrar significa rehacer todas esas conexiones.

Cómo se acumula el costo

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

• 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
• Más integraciones y dashboards conectados

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.

Por qué el open-source cambia la ecuación

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.

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

La pregunta que hay que hacerse al evaluar una plataforma

Antes de firmar cualquier contrato con una plataforma de datos, hay una pregunta que muy pocas empresas se hacen:

¿Cuánto me costaría migrar en 3 años?

No el costo de migrar hoy, cuando los datos son pocos y el sistema es nuevo. El costo de migrar en 3 años, cuando tenés 3 años de datos acumulados, 15 integraciones, 40 dashboards, y un equipo que solo sabe esa plataforma.

Si esa respuesta no está clara, hay algo que no estás viendo.

Un ejemplo concreto de lock-in

Una empresa de SaaS B2B implementó Snowflake hace 2 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.

Eligieron quedarse en Snowflake por el costo de transición. Eso es el lock-in funcionando exactamente como está diseñado.

Cuándo el lock-in 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 de la plataforma
• Cuando el compliance específico de la industria requiere certificaciones que solo tienen los vendors enterprise

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 año 1 que en 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.