n8n Data Tables : quand se passer d'une base de données externe

Un besoin revient sans cesse dans les workflows n8n : garder une trace d'un état entre deux exécutions — quels emails ont déjà été traités, combien de fois un utilisateur a déclenché tel webhook aujourd'hui, quels documents restent à traiter dans une file. Jusqu'à récemment, la réponse passait presque toujours par un service externe (Supabase, Airtable, Google Sheets) même pour un besoin de trois colonnes. Depuis la version 1.113, n8n propose Data Tables : un stockage structuré intégré à l'instance, sans base de données à provisionner. Ce guide explique ce que couvre réellement cette fonctionnalité, comment l'utiliser, et où s'arrêtent ses limites.

Qu'est-ce que n8n Data Tables

Data Tables (encore en beta) ajoute à n8n des tables de données persistantes, avec des colonnes typées (texte, nombre, booléen, date, JSON) et des lignes que vos workflows peuvent créer, lire, mettre à jour et supprimer. Contrairement à un simple stockage clé-valeur, chaque table a un schéma défini à l'avance dans l'interface, dans un onglet dédié Data Tables accessible depuis le menu de gauche.

La fonctionnalité est disponible sur tous les plans, y compris en self-hosted sur la Community Edition — pas besoin de licence Enterprise pour en profiter. Les tables sont scopées par projet : seuls les membres du projet concerné (ou vous-même, pour un espace personnel) peuvent y accéder, ce qui évite qu'une table de test créée pour un client se retrouve visible ailleurs.

Cas d'usage concrets

Data Tables cible des besoins de stockage léger, exactement le type de problème qui pousse d'habitude à ouvrir un projet Supabase juste pour trois colonnes :

• Déduplication : enregistrer l'ID de chaque élément déjà traité (email, ticket, ligne de flux RSS) pour ne jamais retraiter deux fois la même donnée entre deux exécutions — un besoin qui revient dans presque tous les workflows de tri d'emails par IA ou de veille concurrentielle.
• Limitation de fréquence : compter combien de fois un utilisateur ou une clé API a déclenché un workflow dans une fenêtre de temps donnée, en complément des bonnes pratiques décrites dans notre guide sur les erreurs 429.
• File d'attente : maintenir une liste d'éléments à traiter et les marquer comme terminés au fil des exécutions, utile pour lisser un traitement par lots sans dépendre d'un mode queue Redis complet quand le volume ne le justifie pas.
• Cache : stocker le résultat d'un appel API coûteux (embedding, résumé, enrichissement) pour éviter de le refaire à chaque exécution — un complément direct à notre guide sur le suivi du coût des appels IA.

Le node Data Table : opérations et types de colonnes

Trois façons d'interagir avec une Data Table : le node Data Table dans le canvas d'un workflow, l'endpoint de l'API DataTable, ou directement l'onglet Data Tables de l'interface pour une consultation manuelle. Le node expose les opérations attendues — insertion, récupération (avec filtres), mise à jour, suppression — configurables sans écrire de requête.

Chaque colonne se déclare avec un type strict (texte, nombre, booléen, date ou JSON pour les structures plus complexes), ce qui évite l'écueil classique d'un tableur où une colonne censée contenir des dates finit par mélanger formats texte et nombres. Un point à connaître : l'accès programmatique direct depuis un node Code n'est pas pris en charge. Toute lecture ou écriture doit passer par le node Data Table dans le flux du workflow ; un node Code peut ensuite manipuler les données une fois récupérées, mais pas interroger la table lui-même.

Exemple : déduplication des emails déjà traités

Dans un workflow de tri d'emails proche de celui du Pack Inbox IA (79 €), un node Data Table placé juste après le trigger IMAP peut vérifier si l'ID du message existe déjà dans une table emails_traites avant de lancer la classification IA. Si oui, le workflow s'arrête là (via un node IF) ; sinon, il traite le message puis insère son ID dans la table. Ce garde-fou, combiné à un Error Workflow correctement configuré, évite les doubles traitements en cas de nouvelle tentative après une panne — sans avoir besoin de créer un projet Supabase pour une seule colonne d'IDs.

Les limites à connaître

Data Tables ne remplace pas une base de données. Trois limites structurantes :

• Stockage plafonné : 50 Mo au total par instance par défaut (ajustable en self-hosted via la variable d'environnement N8N_DATA_TABLES_MAX_SIZE_BYTES), avec des avertissements à 80 % du quota. Au-delà, les insertions et mises à jour échouent en erreur d'exécution — largement suffisant pour une file ou un cache, beaucoup trop juste pour une base documentaire.
• Pas de requêtes avancées : ni jointures complexes, ni index de performance pour de gros volumes, ni langage de requête élaboré. Adapté au stockage léger à modéré, pas à des dizaines de milliers de lignes interrogées en continu.
• Pas d'accès direct depuis le Code node, comme évoqué plus haut — une contrainte à intégrer dès la conception si votre logique s'appuie beaucoup sur JavaScript personnalisé.

Data Tables vs Supabase ou Postgres : quand choisir quoi

Besoin	Data Tables	Supabase / Postgres
Déduplication, cache, petite file d'attente	✅ Suffisant, zéro configuration externe	Fonctionne, mais surdimensionné
Volume important, requêtes complexes, jointures	❌ Non prévu pour ça	✅ Node Postgres ou Supabase
Base vectorielle pour du RAG	❌ Pas de type vectoriel	✅ pgvector
Piste d'audit avec conservation longue durée	⚠️ Limite de 50 Mo à surveiller	✅ Voir notre guide RGPD, proche du Pack Conformité & Audit (149 €)
Accès depuis un Code node	❌ Non supporté	✅ Requêtes SQL libres

La règle pratique : si la donnée ne sert qu'à faire tourner la logique interne d'un workflow (état, dédoublonnage, cache court terme), Data Tables évite un service externe entier pour un besoin de quelques colonnes. Dès que la donnée doit être interrogée en dehors de n8n, dépasser quelques dizaines de milliers de lignes, ou stocker des vecteurs, une vraie base reste le bon choix.

Pourquoi structurer plutôt que bricoler

L'alternative la plus courante à Data Tables, avant sa sortie, consistait à détourner un Google Sheet ou un tableau Airtable pour jouer le rôle de mini-base — une pratique répandue, mais qui hérite des angles morts classiques des feuilles de calcul utilisées comme système de données. Une étude de référence de Panko (What We Know About Spreadsheet Errors, Journal of End User Computing, 1998 — voir sur Google Scholar) montre que 20 à 40 % des feuilles de calcul en usage réel contiennent au moins une erreur non triviale, souvent due à l'absence de typage strict et de contrôle de schéma. Une table typée avec des colonnes déclarées à l'avance, même minimaliste comme celle de Data Tables, élimine une bonne partie de cette classe d'erreurs par construction — sans pour autant remplacer une base relationnelle complète pour les besoins qui la justifient réellement.

Pour aller plus loin

Data Tables comble un vrai vide entre « aucun état persistant » et « monter un projet Supabase pour trois colonnes » : parfait pour la déduplication, le cache ou une petite file d'attente, à réserver aux volumes modestes tant que la fonctionnalité reste en beta. Les workflows des packs FlowKit s'appuient sur Supabase pour leurs besoins de fond (file d'attente d'emails, base vectorielle, piste d'audit), mais rien n'empêche d'ajouter une Data Table locale pour un garde-fou léger — une bonne façon de tester l'idée avant, éventuellement, de migrer vers une base complète si le volume grandit.