
Snowflake llevó el 15 de octubre a disponibilidad general el data mirroring para Snowflake Postgres, su oferta de base de datos transaccional gestionada. La función replica de forma continua tablas de una instancia de Snowflake Postgres hacia una base de datos Snowflake, con un desfase mínimo y sin pipelines de ETL, procesos por lotes ni conectores de terceros de por medio. Está disponible en AWS y Azure.
El funcionamiento es directo: cada inserción, actualización, borrado o cambio de esquema que ocurre en el origen aparece automáticamente en el destino. Las filas nuevas quedan visibles para las consultas de Snowflake en unos 30 segundos, sin que haya que ajustar ningún bucle de sondeo. La función incorpora además un feed de cambios de siete días: cada operación queda disponible como una fila consultable, lo que permite auditar o reprocesar lo ocurrido en ese periodo sin depender de los logs del motor origen.
Para un equipo de datos, la propuesta sustituye una pieza de arquitectura que hasta ahora requería una herramienta de captura de cambios externa —Fivetran, Debezium o un conector propio— para mover el dato operacional desde una base transaccional hacia el almacén analítico. Si la base origen ya es Snowflake Postgres, esa capa de ingestión desaparece: la replicación es una característica de la plataforma, no un componente adicional que haya que desplegar, vigilar y actualizar por separado.
El matiz importante está en el alcance. La función solo cubre Snowflake Postgres, la base de datos transaccional propia de Snowflake lanzada en febrero de este año, no cualquier instancia de PostgreSQL externa. Un equipo que ya tenga su transaccional en Amazon RDS o Cloud SQL no puede aplicar esto directamente: seguiría necesitando su herramienta de CDC habitual, o plantearse migrar la base operacional a Snowflake Postgres para beneficiarse de la réplica nativa, lo que es una decisión de arquitectura bastante mayor que activar una función.
Aun con esa limitación, la dirección es clara: los grandes proveedores de almacén analítico están empujando a integrar también la capa transaccional, para que la ingestión deje de ser un problema de integración entre productos y pase a ser una propiedad de la plataforma. Conviene seguir de cerca si otros almacenes replican el mismo movimiento sobre sus propias ofertas de base transaccional, porque de confirmarse la tendencia, el conector de CDC genérico dejará de ser la pieza por defecto en cualquier arquitectura nueva y pasará a reservarse para los casos en que el origen vive fuera del propio almacén.
Más en Dataprix: sección de integración de datos de Dataprix
Fuente: Snowflake (notas de lanzamiento)
Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.