N8n Data Tables Official

n8nOfficialPublished by n8n

Skill
Tool integration
Automation and integrations
Apache-2.0
No issues found

From the author

Use when working with n8n's built-in Data Tables, designing schemas, inserting/updating/upserting rows, deduping, or querying. Triggers on "Data Table", "data table", `n8n-nodes-base.dataTable`, "dedup", "idempotency", "lookup", "persistent state", "store across executions", or any schema design discussion inside n8n.

— the description by n8n

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Data Tables provide a native, tabular storage solution directly within n8n, enabling workflows to maintain persistent state, manage lookup tables, and handle deduplication or audit trails. Designed for small-to-moderate data volumes, they offer CRUD operations via the dataTable node. This skill covers schema design, relational modeling without foreign keys, and effective patterns for idempotency and stateful processing.

What it does

Provides persistent, tabular storage for lookup tables, event logs, and state tracking.
Supports standard CRUD operations: insert, upsert, update, get, and delete.
Enables deduplication patterns using rowExists and rowNotExists operations.
Allows for relational modeling by referencing parent IDs in child tables.
Handles complex data types by storing them as stringified JSON with _object suffixes.
Automatically manages system columns: id, createdAt, and updatedAt.

When to use it

When you need persistent state that survives across multiple workflow executions.
For lookup tables containing stable reference data like tax rates or feature flags.
When implementing deduplication that requires queryable state or row-level logic.
For building audit trails or event logs that need to be queried later.
When you need to manage per-tenant or per-user state within n8n.

Advantages

Native integration eliminates the need for external database connections for simple state.
Simplifies workflow logic for idempotency and deduplication.
Provides a consistent interface for managing tabular data directly in the n8n UI.
Supports flexible schema design with automatic timestamping.
Enables powerful filtering and sorting capabilities for retrieved data.

Usage examples

“How do I implement a deduplication pattern that skips processing for existing items?”: Use the rowNotExists operation with a filter on your unique identifier (e.g., arxivId). Items that already exist in the table are dropped, while new items pass through to the next node for processing.
“How should I store nested JSON objects in a Data Table?”: Since Data Tables only support primitives, stringify your JSON object using JSON.stringify() and store it in a column suffixed with _object (e.g., keyInsights_object). Parse it back using JSON.parse() when reading.
“How do I perform an upsert operation in n8n?”: Use the upsert operation, set the matchType to allConditions, and define your filter conditions. The node will automatically update the row if a match is found or insert a new row if it does not exist.
“What should I do if the Data Table UI says 'Currently no items exist'?”: This is a known UI display quirk. Verify your mappings via get_workflow_details; if the data is correct there, simply click the reload button on the columns parameter to refresh the UI display.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/n8n-io/n8n-data-tables-official/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip n8n-data-tables-official.zip -d .agents/skills

Documentation by n8n

n8n Data Tables

Data Tables are n8n's built-in tabular storage: real tables inside the n8n instance with columns, types, rows, and CRUD via the dataTable node and data-table MCP tools.

Use them for local persistent state: lookup tables, recent events, per-session inventories, counters, idempotency tracking, dedup state when there's row-level logic or external visibility (plain "have I seen this value?" dedup belongs in the Remove Duplicates node). Small-to-moderate volume (tens of thousands of rows fine, millions belong in a real DB).

Non-negotiables

System-managed columns + external IDs. Three columns auto-exist on every table: id (bigserial), createdAt, updatedAt. Don't declare them in create_data_table (errors or shadows the system column). Don't write them on insert. For domain identifiers from outside (arxivId, stripeCustomerId, requestId), add a separate column and key dedup/lookup on that.
Only primitives in columns, nested data uses string + _object postfix. No JSON/object/array column types exist. For nested data (arrays, parsed objects), use a string column with JSON.stringify(...) on write and JSON.parse(...) on read. Mark the column with _object (e.g., keyInsights_object). The postfix is the contract that tells readers to parse. See references/SCHEMA_DESIGN.md.

Strong defaults

Don't add a Set node before a Data Table node to modify fields. The Data Table node's per-column expression slots are just as powerful as Set fields, so the Set node is doing zero work the Data Table node can't do itself. (Same Set-node antipattern called out in n8n-expressions-official.)
Match n8n's column casing: camelCase. The auto-managed columns are camelCase (createdAt, updatedAt), so user columns read more cleanly when they match: arxivId, paperId, taxRate. Mixed casing in the same query (createdAt >= ... AND arxiv_id eq ...) reads as a typo. Keep the _object postfix on stringified-blob columns regardless (keyInsights_object), the underscore is a contract marker, not casing.

Verify the columns parameter via get_workflow_details after create/update. The UI has a display quirk in manual mapping mode ("Currently no items exist" with no actual data loss). Checking the JSON confirms what's persisted.
Relational design works when the shape calls for it. For genuine parent-child data (papers → summaries, customers → orders), reference parents by id, name columns explicitly (paperId, customerId), and enforce integrity in workflow logic. Don't force it on flat use cases (dedup, lookup, audit) where there's no relationship to model.
Storage format is not interface format. Parse _object fields before returning them from a sub-workflow. Callers should never receive stringified shells they have to parse themselves. See references/SCHEMA_DESIGN.md "Storage format ≠ interface format".

The default columns

Every Data Table has these whether you declare them or not:

Column	Type	Behavior
`id`	bigserial / number	Auto-incrementing primary key. n8n assigns on insert, and you can't write to it. Returned in the insert response.
`createdAt`	timestamp	Set automatically on insert.
`updatedAt`	timestamp	Refreshed automatically on each update.

In practice:

Don't declare them in create_data_table. Already there.
Use them in queries without your own timestamp columns. "Created today": createdAt >= '<today ISO>'. "Updated since last sync": updatedAt >= $('Last Sync').item.json.timestamp.
Don't use them as cross-system identifiers. Auto-id is internal, and resets on table recreate or instance migration. For domain identifiers, use your own column.

Relational design when the shape calls for it

Data Tables don't enforce foreign keys, but you can still model parent-child data across tables when the data genuinely has that shape. The catch: integrity is your responsibility, not n8n's.

Reference parent rows by id. A child table holds the parent's id in a column.
Document references in column names. paperId, customerId, eventId make the relationship obvious.
Enforce integrity in workflow logic. Before inserting a child, look up the parent. Before deleting a parent, decide what happens to children (delete, orphan, archive). n8n won't cascade.
Watch for stale references. Children pointing at deleted parents are silent bugs. Soft-delete, or run cleanup workflows.

For complex relational structure (3+ tables with joins, transactional writes), reach for an actual SQL DB.

Operations: which one for what

Operation	When
`insert`	Always-add. New row, n8n assigns `id`.
`upsert`	"Add if new, update if exists." Needs a `matchType` and filter to decide existence.
`update`	"Modify rows matching this filter." No insert if no match.
`get`	Fetch rows matching a filter (returns 0+). Supports `orderBy`, `limit`, `returnAll`.
`deleteRows`	Remove rows matching a filter.
`rowExists` / `rowNotExists`	Boolean-style filter against incoming items. Common for dedup branching.

For the full operation surface (filter syntax, matchType, sort patterns), see references/OPERATIONS.md.

The "Currently no items exist" UI quirk

When the SDK saves manual-mode column mappings (mappingMode: 'defineBelow'), the n8n UI's "Values to insert" pane can render empty ("Currently no items exist") even though runtime persists data correctly. If the user reports the Insert node "looks broken" or "has no fields," tell them: it's a UI display issue, press the reload (refresh) button on the columns parameter, and it repopulates the schema and the mappings render. No data loss, safe to do anytime.

Common patterns

Dedup by external ID

Default to the Remove Duplicates node ("items seen in previous executions" mode) for plain "have I seen this value?" dedup. It's a one-node solution with an internal store, no schema to maintain. Data Tables only earn the slot when there's a reason for the dedup state to live in a real table:

You'll query or inspect the dedup state. Dashboards, audit, "what have we processed in the last week?"
Row-level logic on hits. Per-category TTL ("expire after 30 days for category A, 7 days for category B"), conditional re-process based on stored state, branching on a status column.
Per-tenant or per-user namespacing that the Remove Duplicates history-store can't express.

When that bar is met:

[Source: { arxivId, ... }]
   ↓
[Data Table Get: filter arxivId eq $json.arxivId, limit 1]
   ↓
[IF: result has items?]
   ├── Yes → [Skip, or apply row-level logic from the stored row]
   └── No  → [Process] → [Data Table Insert: { arxivId, ...rest }]

For the full pattern surface (upsert, rowNotExists, Get+IF, idempotency keys), see references/DEDUP_PATTERNS.md.

Lookup tables

Stable reference data (country → tax rate, plan → feature flags). Edited via n8n UI, and workflows read at execution:

[Data Table Get: filter country eq $json.country, limit 1]
   ↓
[Use the looked-up row's taxRate, etc.]

Recent events / audit trail

Append-only insert, queried later:

[Workflow event] → [Data Table Insert: { userId, eventType, payloadSummary }]

createdAt makes "recent events in the last hour" trivial without your own timestamp.

Reference files

File	Read when
`references/SCHEMA_DESIGN.md`	Designing columns/types, the no-FK relational pattern, mapping mode (`defineBelow` vs `autoMapInputData`), when Data Tables are the wrong tool
`references/OPERATIONS.md`	Operation surface (insert/upsert/update/get/delete/rowExists), filter syntax, matchType, orderBy
`references/DEDUP_PATTERNS.md`	Idempotency keys, RemoveDuplicates node vs Data Table dedup, search-then-insert vs upsert

For expression discipline ($json vs $('Node Name').item.json, the Set-node antipattern), see n8n-expressions-official. For Merge convergence and same-shape branches, see n8n-node-configuration-official references/MERGE_NODE.md.

Anti-patterns

Anti-pattern	What goes wrong	Fix
Set node upstream of Insert "to shape the input"	Extra node for nothing, classic Set antipattern, field shape drifts when you add columns	Map directly in the Insert node's per-column slots, OR rename upstream fields to enable auto-map
Declaring `id`, `createdAt`, `updatedAt` in `create_data_table`	Errors, or shadows the system column with a user column that doesn't auto-update	Don't declare them, they're already there
Storing application-critical data in Data Tables	If n8n breaks, you lose access	Use a real DB for data you can't lose
Cross-app system-of-record in Data Tables	Hard to share with non-n8n consumers, awkward query surface	Use a real DB
Treating auto-`id` as a stable cross-instance identifier	Resets if the table is recreated, not portable	Use a domain ID column (`arxivId`, `requestId`) for cross-system references
Foreign-key cascade assumptions	n8n doesn't cascade, deleted parents leave orphan children	Soft-delete, or run cleanup workflows that maintain referential integrity
Referencing an immediately-prior node when an intermediate stripped json	Insert silently writes NULLs for fields that "should be there"	Reference a stable upstream node by name, or use a NoOp/Merge convergence anchor (see `n8n-expressions-official` and `n8n-node-configuration-official` `references/MERGE_NODE.md`)
Manual-map mode + Set node to fix "Currently no items exist"	Doesn't fix anything, that's a UI quirk, you've added a useless Set node	Verify via `get_workflow_details` that `columns.value` has your mappings, runtime is fine. Tell the user to press the reload button on the columns parameter to make the UI render the fields.

Verification before publishing

After creating or updating a workflow that uses Data Tables:

validate_workflow passes.
get_workflow_details and inspect each Data Table node's columns. Both value and (for manual map) schema populated.
test_workflow with pinned data. Insert response should include id, createdAt, updatedAt.
Inspect actual Data Table contents via UI or follow-up Get to confirm columns aren't silently NULL.

Step 4 especially the first time you wire a new Insert. Context-stripping intermediates + manual map + UI quirk silently produce NULL columns.

Files

ATTRIBUTION.mdAdded by AutoGineer854 B
LICENSELicence file added by AutoGineer11.0 KiB
SKILL.md11.1 KiB
references/DEDUP_PATTERNS.md5.2 KiB
references/OPERATIONS.md5.6 KiB
references/SCHEMA_DESIGN.md10.9 KiB

references/DEDUP_PATTERNS.md

Dedup patterns

"Have we processed this before?" is one of the most common workflow needs, and most of the time the answer doesn't need a Data Table. The Remove Duplicates node has a built-in mode for it: a one-node solution with an internal store. Data Tables earn the slot only when the dedup state needs to do more than answer "seen / not seen."

Default: `Remove Duplicates` node

For plain "seen this exact value before?" with no associated data:

{
    type: 'n8n-nodes-base.removeDuplicates',
    parameters: {
        operation: 'removeItemsSeenInPreviousExecutions',
        dedupeValue: '={{ $json.entryId }}',
        options: {
            historySize: 10000,
        },
    },
}

Fits when:

Dedup is JUST about the value, no metadata to attach.
History size limit (~10k default) is enough.
You don't need to inspect or query "what have we seen?"

When Data Tables earn the slot

Reach for a Data Table when you need any of:

Queryable dedup state. Dashboards, audit, "what have we processed in the last week?"
Row-level logic on hits. Per-category TTL ("expire after 30 days for category A, 7 days for B"), conditional re-process based on stored state, branching on a status column.
Per-tenant / per-user namespacing beyond what the history-store can express.
TTL with cleanup. Daily cleanup of stale markers.
Volume past ~10k history items.

When that bar is met, pick one of three Data-Table patterns by the branch behavior you want.

Pattern 1: `upsert` (cleanest)

For "first time → insert, subsequent → update" with no branching:

[Source: { arxivId, ... }]
   ↓
[Data Table Upsert: matchType allConditions, filter arxivId eq <id>, columns ...]
   ↓
[Continue with the inserted/updated row's id]

Upsert returns id, createdAt, updatedAt whether insert or update, so downstream doesn't need to know which.

When wrong:

You need to skip work on duplicates. Upsert always touches the row, wastes compute. Use Pattern 2.
You need a "first time only" side effect. Upsert can't distinguish without an extra get to compare timestamps.

Pattern 2: `rowNotExists` + Insert (skip duplicates)

To skip processing for existing rows:

[Source: { arxivId, ... }]
   ↓
[Data Table rowNotExists: filter arxivId eq <id>]
   ↓ (only new items pass through)
[Process: download, summarize, etc.]
   ↓
[Data Table Insert: { arxivId, ... }]

rowNotExists filters input, and existing rows drop silently.

When wrong:

You also need to handle existing items (return cached result). Use Pattern 3.

Pattern 3: Get + IF (full control)

For both branches, "process new" AND "return existing":

[Source: { arxivId, ... }]
   ↓
[Data Table Get: filter arxivId eq <id>, limit 1, alwaysOutputData=true]
   ↓
[IF: $json.id exists?]
   ├── Yes (already processed) → [Return existing row's data]
   └── No (new) → [Process] → [Data Table Insert] → [Return new row's data]

Two notes:

alwaysOutputData: true on Get. Without it, no-match produces zero items and the pipeline silently does nothing. With it, Get always emits one item (possibly empty), and the IF can branch.
Both branches must produce the same JSON shape. Otherwise downstream $json.x breaks depending on which branch fired. See n8n-node-configuration-official references/MERGE_NODE.md for the Merge convergence anchor.

Pattern decision tree

Need to dedup?
├── Plain "seen this value?" with no metadata, no TTL, fits in ~10k history?
│   └── Default: Remove Duplicates node, no Data Table
│
└── Need queryable state, row-level logic, TTL, or per-tenant namespacing?
    ├── Want "skip duplicates" (no work on existing)?     → Pattern 2: rowNotExists + Insert
    ├── Want "first-time insert, subsequent update"?      → Pattern 1: upsert
    └── Want both branches (process new, return cached)?  → Pattern 3: Get + IF + same-shape branches

Idempotency keys

For webhook workflows safe under retries:

[Webhook receives X-Request-Id header]
   ↓
[Data Table Get: filter requestId eq <id>, limit 1, alwaysOutputData=true]
   ↓
[IF: row exists?]
   ├── Yes → [Respond with cached response stored on the row]
   └── No  → [Process]
              ↓
            [Data Table Insert: { requestId, responseBody, ... }]
              ↓
            [Respond with the response]

Two design choices:

Store response or just marker? Storing lets you serve the same answer on retry (full idempotency). Marker-only suffices when clients retry only to confirm receipt.
TTL? Markers shouldn't live forever. Run a daily cleanup deleting rows where createdAt < now - <retry window>.

Volume notes

Data Tables handle tens of thousands of rows. Past that, dedup queries get slow.
For millions of keys, use a real cache (Redis, DynamoDB).
For hundreds of rows with no metadata, the Remove Duplicates default is simplest.

Cross-references

Filter syntax: OPERATIONS.md.
Where dedup fits in API workflows: n8n-error-handling-official references/API_WORKFLOWS.md.
alwaysOutputData: true rule: n8n-node-configuration-official and the SDK reference's "Handle empty outputs."

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

n8n

Publisher

n8n (Official)

Source

n8n-io/skills · skills/n8n-data-tables-official · commit 27b6b9f

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

AutoGineer is not affiliated with or endorsed by n8n.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download n8n-data-tables-official.zip