n8n Data Tables 是 n8n 内置的表格化存储能力：在 n8n 实例内创建真实的数据表，包含列、类型与行，并通过 dataTable 节点和 data-table MCP 工具完成增删改查。
【用途】 主要用于本地持久化状态，例如：查找表（lookup tables）、近期事件、按会话的清单、计数器、幂等性跟踪，以及在需要行级逻辑或外部可见性时的去重状态。对于单纯的“这个值我见过吗”式去重，文档建议优先使用 Remove Duplicates 节点；只有当去重状态需要被查询、检查、带行级逻辑或按租户/用户命名空间时，Data Tables 才更合适。
【主要能力】
- 系统管理列：每张表自动存在三个列——id（bigserial / number，插入时由 n8n 分配，不可写入，插入响应会返回）、createdAt（timestamp，插入时自动设置）、updatedAt（timestamp，每次更新自动刷新）。不要在 create_data_table 中声明它们，也不要在插入时写入。不要把它们当作跨系统标识符，因为表重建或实例迁移时自动 id 会重置。
- 列类型限制：只支持基本类型，不存在 JSON/object/array 列类型。嵌套数据（数组、解析后的对象）需使用 string 列，写入时 JSON.stringify(...)，读取时 JSON.parse(...)，并以 _object 后缀标记（如 keyInsights_object），该后缀是告知读取方需要解析的契约。
- 操作类型：insert（总是新增，n8n 分配 id）、upsert（不存在则新增，存在则更新，需要 matchType 和 filter 判定存在性）、update（修改匹配 filter 的行，无匹配则不插入）、get（按 filter 获取 0 行或多行，支持 orderBy、limit、returnAll）、deleteRows（删除匹配 filter 的行）、rowExists / rowNotExists（针对传入项做布尔式过滤，常用于去重分支）。
【使用方式】
- 列名大小写：建议匹配 n8n 的 camelCase 风格（如 arxivId、paperId、taxRate），与自动管理列 createdAt、updatedAt 保持一致。_object 后缀保持原样，它是契约标记而非大小写约定。
- 对插入节点上游的 Set 节点：文档将其列为反模式。Data Table 节点按列提供表达式槽位，能力与 Set 字段相当，因此不需要额外 Set 节点来“整形输入”，否则会增加无意义节点，且新增列时字段形状容易漂移。可直接在插入节点的按列槽位映射，或重命名上游字段以启用自动映射。
- 验证：create/update 之后用 get_workflow_details 检查 columns 参数。UI 在手动映射模式下有一个显示怪癖——可能显示“Currently no items exist”但实际并未丢失数据。若用户反馈插入节点“看起来坏了”或“没有字段”，可让其点击 columns 参数上的重载（刷新）按钮，schema 与映射会重新渲染，无数据丢失，随时可安全操作。
【适用场景与关系建模】
- 查找表：稳定的参考数据（如国家→税率、套餐→功能开关），在 n8n UI 中编辑，工作流执行时读取。
- 近期事件/审计轨迹：仅追加插入，后续查询；createdAt 让“最近一小时的事件”查询无需自建时间戳列。
- 去重：按外部 ID 去重时，先 Get 再 IF 判断是否存在，或使用 upsert、rowNotExists 等模式。
- 关系设计：Data Tables 不强制外键，但数据确实呈父子形状时仍可建模——子表以列保存父行 id，列名显式体现关系（paperId、customerId、eventId），完整性由工作流逻辑负责：插入子行前先查父行，删除父行前决定子行如何处理（删除、孤立、归档），并留意陈旧引用（子行指向已删除父行会是静默 bug），可用软删除或清理工作流维护。对于复杂关系结构（3 张以上表且有连接、事务写入），应使用真实 SQL 数据库。
- 存储格式不等于接口格式：从子工作流返回前应解析 _object 字段，调用方不应收到需要自行解析的字符串外壳。
【限制与反模式】
- 不要把应用关键数据存放在 Data Tables 中，若 n8n 出问题将失去访问；也不要把 Data Tables 当作跨应用系统的记录源，难以与非 n8n 消费者共享、查询面笨拙。
- 不要假设外键级联，n8n 不会级联删除。
- 不要引用一个被中间节点剥离 json 的紧邻上游节点，否则插入会静默写入 NULL；应引用按名称定位的稳定上游节点，或使用 NoOp/Merge 收敛锚点。
- 手动映射模式加 Set 节点并不能修复“Currently no items exist”，那只是 UI 怪癖。
- 数据量方面：中小规模（数万行没问题），百万级应放入真实数据库。
【发布前验证建议】 创建设计 Data Tables 的工作流后：确认 validate_workflow 通过；用 get_workflow_details 检查每个 Data Table 节点的 columns，确保 value 与手动映射时的 schema 均已填充；用固定数据 test_workflow，插入响应应包含 id、createdAt、updatedAt；通过 UI 或后续 Get 检查 Data Table 实际内容，确认列没有被静默置为 NULL（首次连接新的插入节点时尤其重要）。
以上为资料中明确提供的内容；关于具体收费、价格、支持的平台或版本等信息，暂未提供。