Durante años, uno de los argumentos más potentes de Snowflake ha sido Secure Data Sharing: compartir datos vivos, sin copias y sin pipelines. Pero tenía una letra pequeña evidente: el consumidor también tenía que estar en Snowflake (con su propia cuenta o con una *reader account*).
En la práctica, eso dejaba fuera a muchos socios, clientes y equipos internos que trabajan con otros motores. Y para ellos volvíamos a lo de siempre: exportaciones a ficheros, SFTP, réplicas y procesos ETL que alguien tiene que mantener.
El 2 de noviembre de 2026 Snowflake anunció la disponibilidad general (GA) de Open Data Sharing. Ya no es una preview: es una funcionalidad lista para producción que permite compartir datos vivos y de solo lectura de tablas Iceberg gestionadas por Snowflake con consumidores que no tienen cuenta de Snowflake.
Qué es Open Data Sharing
La idea es sencilla y muy alineada con la apuesta de Snowflake por Apache Iceberg:
1. El proveedor tiene sus datos en tablas Iceberg gestionadas por Snowflake (`CATALOG = ‘SNOWFLAKE’`).
2. Los publica en un listing dirigido a consumidores externos.
3. El consumidor accede con las APIs estándar de Iceberg REST Catalog, desde cualquier herramienta analítica que soporte ese protocolo.
Sin mover datos, sin duplicar almacenamiento y sin construir pipelines. El dato se queda en el almacenamiento del proveedor y el consumidor lo lee siempre actualizado.
Un matiz importante: solo las tablas Iceberg gestionadas por Snowflake son visibles para consumidores externos. Las tablas estándar de Snowflake y las tablas Iceberg gestionadas por un catálogo externo no se comparten por esta vía.
Qué trae la GA
Además de pasar a disponibilidad general, la nota de versión incluye tres capacidades nuevas.
1. Compartición entre regiones
Ahora se pueden ofrecer los datos de un listing a consumidores externos en otras regiones comerciales de AWS y Azure. Cada consumidor externo se asocia a una única región al crearlo, y Snowflake hace el auto-fulfillment*del listing a esa región.
Dos detalles que conviene entender bien:
– La región indica desde dónde se sirve el dato, no desde dónde se conecta el cliente del consumidor.
– La región no se puede cambiar después. Si un socio necesita leer en varias regiones, se crea un consumidor externo por región.
CREATE EXTERNAL CONSUMER socio_eu REGION = 'PUBLIC.AWS_EU_CENTRAL_1';
2. Workload Identity Federation (WIF)
Hasta ahora los consumidores externos se autenticaban con programmatic access tokens (PAT). Con la GA también pueden usar Workload Identity Federation, con proveedores de identidad de AWS, Microsoft Azure, Google Cloud y OpenID Connect (OIDC).
Para mí, esta es la mejora más relevante desde el punto de vista de seguridad. Con un PAT hay un secreto que se muestra una sola vez, que hay que enviar al socio por un canal seguro, custodiar y rotar. Con WIF no se distribuye ningún secreto: el consumidor se autentica con la identidad de su propia carga de trabajo en su nube. Encaja muy bien con lo que comentaba hace unas semanas sobre reducir los secretos duplicados.
3. Acceso de clientes abieros en listings existentes
Se pueden añadir consumidores externos a un listing que ya existe (con `ALTER LISTING`), de modo que un único listing sirve tanto a consumidores Snowflake como a clientes abiertos. Los consumidores Snowflake siguen viendo todos los objetos del share; los externos solo ven las tablas Iceberg gestionadas por Snowflake.
Esto evita mantener dos productos de datos paralelos para el mismo contenido, algo que en un marketplace interno o externo se agradece mucho.
Cómo se monta, a grandes rasgos
El flujo, resumido a partir de la documentación oficial:
1. Permisos: `ACCOUNTADMIN` o un rol con `CREATE EXTERNAL CONSUMER` y privilegios para crear shares y listings.
2. Crear el consumidor externo: `CREATE EXTERNAL CONSUMER`. Es una identidad restringida: no se le pueden asignar roles ni opciones de usuario estándar.
3. Configurar la autenticación: WIF (`ALTER EXTERNAL CONSUMER … ADD WORKLOAD IDENTITY`) o PAT (`ALTER EXTERNAL CONSUMER … ADD PAT`).
4. Preparar los datos en tablas Iceberg gestionadas por Snowflake.
5. Crear el share y conceder `USAGE` sobre base de datos y esquema y `SELECT` sobre las tablas.
6. Crear el listing externo (`CREATE EXTERNAL LISTING`) indicando en el manifiesto la sección `open_sharing` y los consumidores externos destinatarios.
7. Entregar los datos de conexión al consumidor:
CALL SYSTEM$GET_LISTING_URL_FOR_EXTERNAL_CONSUMER('MI_LISTING', 'SOCIO_EU');
Esta llamada devuelve el catálogo, la URI del catálogo, el scope y la URL del token OAuth que el cliente Iceberg REST necesita para conectarse.
Limitaciones a tener en cuenta
Antes de prometer nada a un socio, conviene revisar estas restricciones que recoge la documentación:
– Solo tablas Iceberg gestionadas por Snowflake. Si tus datos están en tablas estándar, toca planificar la migración o crear tablas Iceberg específicas para compartir.
– Cross-region solo en AWS y Azure comerciales. No incluye regiones de Google Cloud ni regiones de gobierno (`GOV`). En Google Cloud solo se admiten consumidores en la misma región del proveedor.
– Las network policies solo se aplican a consumidores de la misma región del proveedor. No las uses como control de seguridad en listings entre regiones.
– Sin failover ni recuperación ante desastres para consumidores externos, de momento.
– Costes de replicación y almacenamiento en el auto-fulfillment entre regiones. Conviene estimarlos antes de abrir un listing a varias regiones.
– No se puede eliminar un consumidor externo mientras algún listing (publicado o no) lo tenga como destinatario.
Conclusión
Open Data Sharing es, en mi opinión, uno de los movimientos más interesantes de Snowflake en el terreno de la interoperabilidad. Durante mucho tiempo la crítica fue que compartir datos con Snowflake era cómodo siempre que todos estuvieran dentro. Con esta GA, Snowflake acepta que el ecosistema es heterogéneo y apuesta por un estándar abierto (Iceberg REST Catalog) como contrato de acceso.
Algunas reflexiones para arquitectos y responsables de datos:
– Productos de datos y data spaces: la combinación de listings, Iceberg y clientes abiertos hace mucho más viable publicar productos de datos para terceros sin imponerles plataforma. Es una pieza muy útil para los espacios de datos sectoriales.
– Gobierno: el proveedor sigue controlando quién accede, a qué y desde qué región. WIF permite hacerlo sin repartir secretos.
– Arquitectura: si compartir con terceros es estratégico para vuestra organización, es un argumento más para que esos datos vivan en Iceberg gestionado por Snowflake.
– FinOps: menos copias y menos pipelines de exportación, pero hay que modelar el coste de la replicación entre regiones.
Echo en falta en la documentación más detalle sobre monitorización y auditoría del uso por parte de los consumidores externos. Será lo primero que pregunten los equipos de seguridad y cumplimiento, así que conviene validarlo en una prueba de concepto.
Podéis leer la nota oficial en la documentación de Snowflake. Para profundizar:
– Compartir datos con consumidores que no usan Snowflake: https://docs.snowflake.com/user-guide/open-data-sharing
– Workload Identity Federation para Open Data Sharing: https://docs.snowflake.com/user-guide/open-data-sharing-workload-identity
– Conectarse a un catálogo de open sharing: https://docs.snowflake.com/user-guide/open-data-sharing-connect
– Hacer listings disponibles para clientes abiertos:https://docs.snowflake.com/collaboration/collaboration-listings-about#label-listing-availability-open-clients
¿Tenéis casos en los que compartir datos con socios que no usan Snowflake os haya obligado a montar exportaciones? Me encantará leerlos en los comentarios.
Foto de portada gracias a BOOM 💥 Photography: https://www.pexels.com/es-es/foto/cielo-manos-sol-cielo-azul-12585927/
