Maintenant que l’architecture Snowflake est posée, on peut passer aux premiers objets qu’on manipule au quotidien, les tables.
Quand tu crées une table Snowflake, tu as plusieurs options :
CREATE TABLE <Table1> ;
CREATE TRANSIENT TABLE <Table2> ;
CREATE TEMPORARY TABLE <Table3> ;
CREATE EXTERNAL TABLE <Table4> ;
Le type de table peut avoir l’air pas très important au début mais en réalité, le choix du type de table joue sur deux choses très important sur la durée de vie de tes données et ta capacité à les restaurer (Time Travel / Fail-safe).... donc sur la facture.
Pourquoi Snowflake propose plusieurs types de tables ?
Snowflake garde l'historique de tes données pour permettre principalement deux choses :
1 - De remonter dans le temps (Time Travel),
2 - D’avoir un dernier filet de sécurité côté Snowflake (Fail-safe).
Plus tu gardes d’historique, plus ton stockage augmente.
Snowflake te laisse donc de choisir, table par table, le niveau de protection dont tu as besoin. C’est exactement ce qui différencie les types PERMANENT, TRANSIENT, TEMPORARY et EXTERNAL.
Les requêtes SQL restent globalement les mêmes, ce qui change c’est la façon dont les données sont conservées.
Permanent tables
Les permanent tables sont le type par défaut. Tu les crées, elles restent là jusqu’à ce que tu les droppes.
Elles supportent le Time Travel avec une rétention qui peut aller jusqu’à 90 jours dans l'offre Entreprise, puis un Fail-safe de 7 derniers jours.
Si tu ne sais pas ce que signifient le Time Travel et le Fail-safe, ce sont deux mécanismes qui te permettent, quand quelqu’un se plante de DELETE ou écrase une table de prod, d’avoir encore une chance de tout récupérer les données.
CREATE TABLE sales_fact (
sale_id NUMBER,
sale_date DATE,
customer_id NUMBER,
amount NUMBER
);
Si tu ne précises rien, tu es en PERMANENT.
Transient tables
Les transient tables ressemblent beaucoup aux permanent : elles persistent tant que tu ne les droppes pas et elles sont accessibles à tous les utilisateurs qui ont les droits.
La différence est subtile mais importante :
Time Travel est limité (0 ou 1 jour) et il n’y a pas de Fail-safe. Une fois la rétention dépassée, c’est terminé.
C’est intéressant pour les tables de staging et les tables intermédiaires donc des données partagées, mais que tu peux rejouer depuis la source si tu les perds. Tu économises du stockage d’historique tout en gardant un minimum de confort.
CREATE TRANSIENT TABLE stg_orders_raw (
order_id STRING,
payload VARIANT,
load_date TIMESTAMP_NTZ
);
Temporary tables
Les temporary tables sont liées à une session. Tu ouvres une session, tu crées ta table, tu bosses, tu fermes la session → la table disparaît.
On s’en sert pour du one-shot, par exemple pour tester des trucs ou créer des tables très éphémères, ou encore pour des jobs qui ont besoin de stocker des résultats intermédiaires, mais uniquement le temps de l’exécution.
CREATE TEMPORARY TABLE tmp_filtered_events AS
SELECT *
FROM raw_events
WHERE event_date >= CURRENT_DATE - 7;
Snowflake peut garder un peu d’historique sur la table, mais de toute façon tout s’arrête avec la session. Pas de Fail-safe non plus.
External tables
Les external tables sont un cas à part.
Ici, la donnée ne vit pas dans le storage Snowflake mais dans un data lake externe (S3, Azure Blob ou Google cloud storage). Snowflake ne garde que des métadonnées et un mapping vers les fichiers.
Tu peux les interroger comme une table classique mais uniquement en mode lecture(SELECT), c-à-d pas possible de faire de INSERT/UPDATE/DELETE. Il n’y a pas de Time Travel ni de Fail-safe et si tu supprimes un fichier dans le lake, Snowflake ne peut évidemment pas le ressusciter.
C’est pratique pour brancher Snowflake sur de la donnée cold ou très volumineuse comme des archives que tu ne veux pas forcément ingérer complètement.
Comment choisir ton type de table ?
Si on simplifie :
- PERMANENT : données critiques, “source de vérité”, besoin de pouvoir revenir en arrière.
- TRANSIENT : staging et tables intermédiaires partagées, que tu sais reconstruire.
- TEMPORARY : travail ponctuel, données intermédiaires très éphémères.
- EXTERNAL : données stockées dans un data lake externe que tu veux requêter depuis Snowflake.
Perso, je pars souvent du principe suivant :
Permanent par défaut, et je bascule en Transient dès que je sais que la donnée est reconstruisible, ou en Temporary quand je suis en mode “atelier SQL / pipeline éphémère”
À toi de jouer
Créons trois tables avec les mêmes données.
USE DATABASE SNOWFLAKE_LEARNING_DB;
USE SCHEMA FORMATION_SANDBOX;
CREATE OR REPLACE TABLE ORDERS_PERMANENT AS
SELECT *
FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS
LIMIT 1000;
CREATE OR REPLACE TRANSIENT TABLE ORDERS_TRANSIENT AS
SELECT *
FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS
LIMIT 1000;
CREATE OR REPLACE TEMPORARY TABLE ORDERS_TEMP AS
SELECT *
FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS
LIMIT 1000;
Regarde leur configuration.
SHOW TABLES LIKE 'ORDERS_%'
IN SCHEMA FORMATION_SANDBOX;
Maintenant choisis le type de table que tu utiliserais dans les trois cas suivants.
1 - Une table de ventes utilisée en production et difficile à reconstruire
2- Une table intermédiaire d'un pipeline que tu peux reconstruire depuis RAW
3- Une table utilisée uniquement pendant une session pour préparer un calcul
Le vrai sujet n'est donc pas seulement de connaître les trois syntaxes.
Il faut surtout savoir quelle protection vaut réellement le coût selon le rôle de la table.
Aller plus loin : Formation Snowflake
J'ai regroupé tous mes articles Snowflake dans un parcours complet.
👉 Maîtriser Snowflake (parcours complet)
Tu prépares la certification SnowPro ? Entraîne-toi avec 700+ questions d'examens blancs chronométrés, corrections détaillées et suivi de progression.
👉 S'entraîner sur DataCertification.fr
Tu veux que je t'accompagne sur ton projet data (Snowflake, ingestion, modélisation, performance, coûts, gouvernance) ?
👉 Réserver un appel de 30 minutes