Gestió de costos a Snowflake: com es cobra i com reduir la factura

Snowflake separa l'emmagatzematge del còmput i cobra pel que fas servir. Aquesta flexibilitat és el seu gran avantatge i també l'origen de les sorpreses a la factura: ningú no compra un servidor, però qualsevol pot deixar un warehouse gran encès o llançar una consulta que recorre tota la taula. Gestionar el cost de Snowflake no consisteix a apagar coses, sinó a entendre què es cobra, mesurar qui ho consumeix i decidir amb dades.

Aquest article explica com factura Snowflake, on sol anar-se'n els diners i quines estratègies apliquem per reduir i optimitzar la despesa sense frenar els equips. Els preus citats són els de la taula de consum de Snowflake a novembre de 2026.

Com cobra Snowflake

La factura té tres partides: còmput, emmagatzematge i transferència de dades. Les tres es liquiden cada mes, sota demanda (On Demand) o contra un import comprat per endavant (Capacity).

El crèdit: la unitat de còmput

Tot el còmput es paga en crèdits. El preu d'un crèdit depèn de tres coses: l'edició de Snowflake (Standard, Enterprise, Business Critical o VPS), el proveïdor de núvol i la regió. A les regions europees habituals (AWS Frankfurt, Azure West Europe, GCP Netherlands) el preu sota demanda és avui de 2,60 USD en Standard, 3,90 USD en Enterprise i 5,20 USD en Business Critical. Amb un contracte Capacity s'aplica un descompte sobre aquest preu a canvi de comprometre consum anual.

La primera decisió de cost, per tant, és anterior a qualsevol consulta: edició i regió. Enterprise costa un 50 % més que Standard per crèdit i aporta funcions com els warehouses multi-cluster, 90 dies de Time Travel o l'emmascarament de dades. Si no es fan servir, s'està pagant per elles.

Virtual warehouses: per segon, amb mínim d'un minut

Un warehouse és el motor que executa consultes i càrregues. Consumeix crèdits per hora segons la mida, i cada mida dobla l'anterior:

Mida	XS	S	M	L	XL	2XL	3XL	4XL
Crèdits per hora	1	2	4	8	16	32	64	128

Tres regles marquen la factura:

• Es factura per segon mentre el warehouse està en marxa, amb un mínim de 60 segons cada vegada que arrenca. Una consulta de dos segons en un warehouse que es desperta per a ella costa un minut sencer.
• Suspès no consumeix res. Per això l'auto-suspend i l'auto-resume són el primer ajust.
• Un multi-cluster multiplica el consum pel nombre de clústers actius en cada moment.

Els warehouses de segona generació (Gen 2) fan servir maquinari més recent i costen 1,35 vegades més per hora a AWS i GCP i 1,25 vegades més a Azure. Com que acaben abans les consultes, poden sortir més barats per feina feta, però no sempre: cal mesurar-ho amb la càrrega real. Els warehouses optimitzats per a Snowpark, amb més memòria, també tenen la seva pròpia taula de preus.

Serveis cloud: la capa que coordina

La capa de serveis cloud autentica, optimitza consultes, gestiona metadades i transaccions. El seu ús es mesura a 4,4 crèdits per hora, però cada dia queden exempts els crèdits equivalents al 10 % del que han consumit els warehouses: només es factura el que excedeix aquest 10 %. A la majoria de comptes no apareix a la factura. Apareix quan hi ha moltíssimes consultes petites de metadades, clonacions massives, eines que llancen SHOW o DESCRIBE en bucle o consultes que es resolen només amb la memòria cau de resultats.

Funcions serverless: còmput que no se suspèn

Algunes funcions fan servir còmput gestionat per Snowflake, sense warehouse. Unes es facturen en «hores de còmput» equivalents a un XS, multiplicades per un factor propi de cada funció; altres, per volum de dades:

• Manteniment de vistes materialitzades i Search Optimization Service: factor 2.
• Tasques serverless: factor 0,9 (0,5 en la modalitat Flex).
• Query Acceleration Service: factor 1.
• Snowpipe: 0,0037 crèdits per GB ingerit.
• Snowpipe Streaming: 0,0037 crèdits per GB sense comprimir a l'arquitectura d'alt rendiment. L'arquitectura clàssica es factura per còmput (factor 1) més 0,01 crèdits per client i hora.
• Clustering automàtic: factor 2 en la modalitat clàssica; a Optima Clustering, 0,007 crèdits per GB sense comprimir, que pot reduir-se segons el solapament de les dades.

Són càrrecs que s'activen una vegada i continuen consumint fins que algú els desactiva. A més, els monitors de recursos clàssics no els cobreixen; per a ells calen els pressupostos (budgets), que veurem més endavant.

Funcions d'IA

Les funcions de Cortex (resums, classificació, embeddings, Cortex Analyst, Cortex Search) es facturen per tokens processats o per unitats, amb els seus propis «crèdits d'IA». Aquests crèdits tenen un preu i una escala de descomptes per capacitat diferents dels de plataforma: el descompte negociat per als crèdits de plataforma no se'ls aplica. Si s'incorporen a un pipeline diari convé mesurar-ne el cost per operació des del primer dia.

Emmagatzematge

Es cobra una tarifa plana per terabyte al mes, calculada sobre la mitjana diària de bytes emmagatzemats ja comprimits. A les regions europees citades està entre 20 i 24,50 USD per TB al mes sota demanda (20 a GCP Netherlands, 23 a Azure West Europe i 24,50 a AWS Frankfurt), amb descomptes per trams en Capacity. El que molts obliden és què s'inclou en aquesta mitjana:

• Les dades actives de les taules.
• Time Travel: les versions anteriors de les dades durant el període de retenció configurat (de 0 a 90 dies en Enterprise).
• Fail-safe: 7 dies addicionals de còpia de seguretat a les taules permanents, que no es poden desactivar.
• Els clons només paguen les dades que canvien respecte a l'original, però les taules copiades amb CREATE TABLE AS paguen íntegres.

Transferència de dades

Portar dades a Snowflake és gratuït. Treure-les cap a una altra regió, un altre núvol o internet es cobra per TB. Afecta les replicacions entre regions, les descàrregues amb COPY INTO a buckets d'un altre núvol i les connexions des de fora de la regió.

Un exemple de factura

Una empresa mitjana amb Snowflake Enterprise a Azure West Europe:

Càrrega	Warehouse	Ús	Crèdits al mes
Càrregues ELT nocturnes	L (8 cr/h)	2 h al dia, 30 dies	480
Informes i Power BI	M (4 cr/h)	8 h al dia, 22 dies	704
Analítica ad hoc	S (2 cr/h)	4 h al dia, 22 dies	176
Total còmput			1.360

A 3,90 USD el crèdit, el còmput són 5.304 USD al mes. Si emmagatzema 10 TB comprimits, l'emmagatzematge afegeix uns 230 USD. El còmput és més del 95 % de la factura, i per això gairebé tota l'optimització es concentra allà. Cal notar, a més, que el warehouse d'informes costa la meitat per hora que el de càrregues i, tot i això, és el que més costa al mes: les hores encès pesen més que la mida.

On se'n van els diners

Quan revisem un compte, els mateixos símptomes es repeteixen:

• Warehouses encesos sense consultes, amb auto-suspend de 10 minuts o desactivat «perquè no trigui a arrencar».
• Mides triades a ull: un XL per a consultes que caben en un S, perquè algú el va pujar un dia per a una càrrega puntual i ningú no el va abaixar.
• Consultes sense poda: SELECT * sobre taules enormes, filtres amb funcions sobre la columna, joins sense condició i consultes que aboquen dades a disc (spilling) per falta de memòria.
• Pipelines massa freqüents: una càrrega cada cinc minuts quan el negoci mira l'informe una vegada al dia.
• Entorns de desenvolupament i proves sense límits, amb la mateixa mida que producció.
• Funcions serverless oblidades: search optimization en taules que ja ningú no consulta així, vistes materialitzades d'un projecte tancat.
• Còpies de taules i Time Travel de 90 dies en dades de staging que es regeneren cada nit.

Vuit estratègies per reduir i optimitzar el cost

1. Mesurar i atribuir abans de tocar res

No es gestiona el que no es mesura. Snowflake exposa a l'esquema ACCOUNT_USAGE tot el necessari:

• WAREHOUSE_METERING_HISTORY: crèdits per warehouse i hora, inclòs el temps ociós.
• QUERY_HISTORY: detall de cada consulta (usuari, rol, warehouse, durada, bytes llegits, spilling).
• QUERY_ATTRIBUTION_HISTORY: crèdits de còmput atribuïts a cada consulta. No inclou el temps ociós del warehouse; aquest cost s'obté per diferència amb WAREHOUSE_METERING_HISTORY i cal repartir-lo amb un criteri propi.
• METERING_DAILY_HISTORY: còmput, serveis cloud i serverless per dia.
• STORAGE_USAGE i TABLE_STORAGE_METRICS: emmagatzematge actiu, Time Travel i Fail-safe per taula.

Amb això es construeix un quadre de cost per equip, aplicació i consulta. Per repartir-lo bé calen dos hàbits: fer servir query tags a cada eina i pipeline, i etiquetes (tags) d'objectes a warehouses i bases de dades amb el centre de cost o el domini responsable. Snowsight inclou a més una vista de gestió de costos amb les consultes més cares.

2. Configurar els warehouses amb criteri

• Auto-suspend curt: 60 segons és un bon punt de partida per a càrregues per lots. Per a BI interactiu pot compensar una mica més, perquè la memòria cau local del warehouse es perd en suspendre'l i la consulta següent triga més.
• Auto-resume activat, sempre.
• Un warehouse per tipus de càrrega (càrregues, informes, ciència de dades), no un de gegant compartit. Permet dimensionar, mesurar i limitar cadascun per separat.
• Començar petit i pujar amb proves. Pujar de mida dobla el cost per hora; només compensa si la consulta acaba en menys de la meitat del temps. Els senyals per pujar són l'spilling a disc remot i les cues; si no n'hi ha, abaixar.
• Multi-cluster per a la concurrència d'usuaris, amb un màxim de clústers raonable, en lloc d'un warehouse més gran. La política Standard arrenca clústers tan bon punt hi ha cua i és l'adequada per a BI interactiu; la política Economy estalvia crèdits a canvi de deixar consultes esperant, i encaixa en càrregues que toleren aquesta espera.
• Temps màxims: STATEMENT_TIMEOUT_IN_SECONDS i STATEMENT_QUEUED_TIMEOUT_IN_SECONDS per warehouse eviten que una consulta oblidada consumeixi tota la nit.
• Avaluar Gen 2 amb la càrrega real: en càrregues pesades sol reduir el cost per feina; en consultes petites, no.

3. Posar límits que avisin i que tallin

• Monitors de recursos (resource monitors): quota mensual de crèdits per compte o per warehouse, amb fins a cinc llindars que notifiquen i, si es vol, un llindar que suspèn el warehouse (al 100 % o en el percentatge que es triï). Per a desenvolupament i proves, llindars agressius; per a producció, notificar al 75 % i al 90 % i suspendre només si hi ha un pla de resposta.
• Pressupostos (budgets): límit mensual de despesa que cobreix també les funcions serverless i permet agrupar objectes. Avisen per correu o webhook quan la previsió supera el límit, però no tallen.
• Permisos: qui pot crear warehouses, canviar-ne la mida o activar funcions serverless. La major part del descontrol ve del fet que qualsevol pot fer-ho.

4. Optimitzar consultes i model de dades

• Aprofitar la poda de particions: Snowflake només llegeix les micro-particions que necessita si els filtres van sobre columnes amb les dades ben ordenades. Carregar les taules grans ordenades per data i afegir clustering keys només quan la taula és molt gran i es filtra sempre per les mateixes columnes.
• Seleccionar només les columnes necessàries: l'emmagatzematge és columnar i cada columna de més es llegeix de disc.
• Evitar funcions sobre les columnes filtrades i les conversions de tipus als joins, que impedeixen la poda.
• Càrregues incrementals en lloc de recalcular-ho tot cada nit; dynamic tables amb un retard objectiu (target lag) d'acord amb el negoci, no al mínim.
• Memòria cau de resultats: una consulta idèntica sobre dades que no han canviat es respon des de la memòria cau durant 24 hores sense gastar crèdits de warehouse. Els quadres amb consultes estables se'n beneficien molt si no se'ls afegeix CURRENT_TIMESTAMP o paràmetres que canvien.
• Revisar el pla d'execució de les 20 consultes més cares cada mes. Sol haver-n'hi una o dues que, reescrites, paguen tota la feina d'optimització.

5. Revisar càrregues i freqüències

• Ajustar la freqüència dels pipelines a quan es fa servir la dada. Un informe diari no necessita una càrrega cada cinc minuts.
• Agrupar tasques petites al mateix warehouse i a la mateixa finestra per amortitzar el mínim de 60 segons i la memòria cau.
• Triar entre Snowpipe (fitxers continus, petits) i COPY per lots (fitxers grans a hores fixes) segons el cas. Fitxers d'entre 100 i 250 MB comprimits carreguen millor que milers de fitxers diminuts.
• Desactivar el que ja no es fa servir: tasques, streams, vistes materialitzades, search optimization.

6. Controlar l'emmagatzematge

• Time Travel per tipus de dada: 1 dia (o cap) en staging i dades derivades que es regeneren; més només on hi hagi un requisit de recuperació.
• Taules transitòries (transient) per a staging i intermedis: no tenen Fail-safe i estalvien els 7 dies extra.
• Eliminar còpies i clons orfes i taules de projectes tancats. TABLE_STORAGE_METRICS mostra quant de cada taula és Time Travel i Fail-safe.
• Moure l'històric fred a taules Iceberg o externes al llac. El preu per TB de l'emmagatzematge estàndard del núvol és semblant al de Snowflake; l'estalvi ve de no pagar Time Travel ni Fail-safe i de poder fer servir els nivells d'emmagatzematge fred del proveïdor, i la dada continua sent consultable.

7. Revisar el contracte

• Passar a Capacity quan el consum és estable: el descompte sobre el preu del crèdit és la mesura de més impacte a partir d'un cert volum.
• Comprovar que l'edició es correspon amb les funcions utilitzades.
• Valorar la regió: el preu del crèdit i del TB varia entre regions europees, i la transferència entre regions no és gratuïta.

8. Fer-ne un costum: FinOps per a dades

Les mesures tècniques es desfan en sis mesos si ningú no les sosté. El que funciona és senzill: un responsable de cost per domini de dades, un quadre que tothom veu, una revisió mensual de les consultes i warehouses més cars, alertes que arriben a qui pot actuar i el cost per informe o per procés com un KPI més de l'equip de dades. És la mateixa lògica que apliquem al govern de les dades: propietaris, mètriques i decisions registrades.

Un pla de 30 dies

1. Setmana 1. Mesurar. Quadre de cost per warehouse, consulta i equip amb ACCOUNT_USAGE; etiquetes a warehouses i query tags a les eines.
2. Setmana 2. Mesures ràpides. Auto-suspend a 60 segons, abaixar una mida els warehouses sense spilling ni cues, monitors de recursos a desenvolupament i proves, temps màxims per consulta.
3. Setmana 3. Consultes. Revisar i reescriure les 20 consultes més cares; ajustar freqüències de pipelines; desactivar serverless sense ús.
4. Setmana 4. Govern. Pressupostos per domini, permisos sobre warehouses, Time Travel i taules transitòries a staging, revisió del contracte i calendari de revisió mensual.

A Bidatia dissenyem i operem plataformes de dades sobre Snowflake, Microsoft Fabric i Databricks, i una de les primeres coses que fem en entrar en un compte existent és exactament aquest pla: mesurar, corregir l'evident i deixar un sistema de control que l'equip pugui mantenir. Si vols que revisem el teu compte, en parlem.