Dans le dernier article sur l’architecture Snowflake, on a vu l'architecture de snowflake et ses trois couches : storage, compute et cloud services.
Ici on zoome sur un truc très concret du storage et c'est les types de 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> ;

Sur le papier ça a l’air pas important. 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.

💡
Nb : Ici je vais parler uniquement des types de tables de base (permanent, transient, temporary, external). Je ne vais pas traiter les Dynamic Tables, qui sont plutôt des objets de pipeline gérés automatiquement par Snowflake. Je ferai un article dédié dessus.

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”