¿Qué es Snowflake, y qué piden las ofertas que lo llevan?

Snowflake es un almacén de datos analítico que se usa desde la nube y al que se le habla en SQL. Con eso ya puedes leer la oferta. Lo que la oferta no te dice —y tampoco la página de producto— es qué trabajo hay detrás, y es justo lo que decide si te encaja o si vas a pasar un mal rato en la primera llamada técnica.

Lo que sigue es lo que veo en las ofertas de datos que paso por delante de candidatos, y lo que comprobaría yo antes de escribir «Snowflake» en un CV.

Qué es, en una frase que te sirva para leer la oferta

Un data warehouse analítico vendido como servicio: no instalas nada y no hay un servidor tuyo. Corre encima de la nube que haya elegido la empresa (AWS, Azure o Google Cloud) y lo que tú ves es una base de datos a la que le mandas SQL. Por debajo no se parece a Postgres ni a SQL Server en casi nada de lo que importa para el trabajo diario.

Un aviso rápido, porque los buscadores lo mezclan: el «esquema en copo de nieve» (snowflake schema) es una forma de modelar un almacén de datos y existía mucho antes del producto. Si la oferta dice «Snowflake» dentro del stack, habla del producto.

Lo que cambia para quien lo opera

La diferencia que todas las ofertas dan por sabida es que el cómputo y el almacenamiento están separados. Los datos viven en un sitio y la máquina que ejecuta tu consulta —un virtual warehouse— es otra cosa, que se enciende y se apaga aparte y a la que tú le pones el tamaño. Puedes tener dos equipos leyendo las mismas tablas sin pelearse por la CPU, y puedes doblar la potencia del proceso de las noches sin tocar nada de lo demás. Está explicado en la propia documentación de Snowflake sobre warehouses.

Para quien viene de administrar un motor clásico, eso tiene consecuencias bastante concretas:

• Desaparece buena parte del trabajo de infraestructura. No parcheas versiones, no dimensionas discos, no montas réplicas ni pruebas restauraciones. Tampoco creas índices: Snowflake organiza el almacenamiento por su cuenta en micro-particiones.
• Lo que se afina es otro juego. Cómo está escrita la consulta y qué tamaño de warehouse la ejecuta. En tablas muy grandes se añade el clustering, que es cómo están agrupados los datos por debajo.
• Los permisos pesan más de lo que esperas. Los roles y los grants son el modelo de seguridad entero, y es lo primero que se rompe en cuanto entran varios equipos a la vez.
• Y aparece una responsabilidad nueva, que es la del apartado de más abajo.

Si vienes de DBA, esto se lee al principio como «me quitan la mitad del trabajo». Es más bien que la mitad cambia de sitio: lo que antes era mantener el servidor arriba ahora es modelar bien y que la factura no se dispare. De lo que no cambia —modelar y saber contar un incidente de verdad— hablé en ¿qué es un DBA?.

Qué piden de verdad las ofertas que lo llevan

Lo primero, y es lo que más gente subestima: Snowflake casi nunca va solo. En el mercado británico, que es uno de los que miro, IT Jobs Watch contaba 510 ofertas permanentes citando Snowflake en los seis meses hasta el 17 de octubre de 2026 —un 0,43 % del total—, y de esas ofertas el 60,2 % pedía además AWS, el 54,1 % SQL, el 48,0 % Python y el 36,3 % modelado de datos. La tecnología que da nombre a la oferta es menos de la mitad del requisito.

En las búsquedas de datos que muevo yo el bloque es el mismo con otros nombres: Snowflake para almacenar y consultar, y dos piezas alrededor —algo que trae los datos, que en las de clientes alemanes es Azure Data Factory, y Apache Airflow para orquestar lo que corre cada noche—. Si en tu CV solo está la pieza del medio, se nota enseguida.

Traducido a lo que se espera que sepas hacer:

• SQL de verdad, no SQL de consultar. Funciones de ventana, CTEs, planes de ejecución y por qué una consulta lee muchos más datos de los que necesita.
• Modelado. Capas (lo que la empresa llame a su raw y a su staging), hechos y dimensiones, claves, historificación. Es lo que distingue a quien ha montado un almacén de quien lo ha consultado.
• Un lenguaje para los procesos, y en la práctica es Python.
• Ingesta y orquestación, aunque la oferta las mencione de pasada: cómo entran los datos y qué pasa cuando un paso falla a las tres de la mañana.
• Permisos y gobierno del dato, en cuanto la empresa pasa de tener un solo equipo tocando el almacén.

Nada de eso se aprende en un tutorial del producto, y es la razón de que un certificado por sí solo no mueva una entrevista. Lo que la mueve es poder contar una carga que se rompió y qué cambiaste para que no se repitiera.

El requisito que casi ninguna oferta escribe: el cómputo se paga por segundo

Esto es lo que separa a quien ha operado Snowflake de quien lo ha usado. El cómputo se factura en créditos por segundo de warehouse encendido, con un mínimo de 60 segundos cada vez que arranca, y cada escalón de tamaño dobla los créditos por hora: un warehouse Small consume el doble que un X-Small. Por eso el auto-suspend viene activado de serie. Está en su documentación, la que enlazo arriba.

La consecuencia práctica es que en Snowflake una consulta mal escrita no «va lenta»: cuesta dinero, y el dinero lo ve alguien que no eres tú. De ahí salen preguntas de entrevista que en un motor clásico no existían, y que te conviene reconocer:

• Por qué separarías el warehouse de las cargas del warehouse de los informes.
• Qué haces cuando un cuadro de mando mantiene un warehouse encendido todo el día.
• Qué tamaño le pondrías a un proceso nocturno, y cómo lo comprobarías.
• Cómo averiguas qué proceso se ha comido el presupuesto del mes.

Si has pasado por eso, escríbelo en el CV con esas palabras. Es lo que casi nadie trae y lo que hace que una ficha pase de «ha tocado Snowflake» a «lo ha llevado».

A quién le sale corto el salto

• De DBA o de BI con SQL fuerte: corto. Ya tienes lo que no se aprende rápido, que es modelar y entender por qué una consulta es cara; lo que te falta es el vocabulario de la plataforma. Eso son semanas, no años.
• De data engineer con Redshift, BigQuery o Synapse: casi nada. Es la misma forma de trabajar con otros nombres, y las ofertas lo aceptan como experiencia equivalente con bastante naturalidad.
• De backend, si tu relación con los datos es un ORM: más largo de lo que parece. Y la parte difícil no es Snowflake, es el modelado.
• De analista que quiere cruzar a ingeniería de datos: Snowflake es un buen sitio por donde entrar, porque tu SQL ya cuenta desde el primer día. Lo que te toca añadir es lo de alrededor: Python y la orquestación.

Y lo de siempre, que vale para cualquier tecnología del stack: antes de ponerte, abre cuatro ofertas con Snowflake dentro y lee el resto del stack. Si lo que lo acompaña ya lo sabes, la decisión está tomada. Si no reconoces nada más de la lista, lo que te falta no es Snowflake. Los rangos y el proceso van en cada búsqueda: puedes verlos en las búsquedas abiertas antes de hablar conmigo.