工作流还在，但切换到 PostgreSQL 后列表像新装的一样空——这通常不是“数据库变量没填好”，而是新库并没有旧实例的数据。
最快解法：不要只改数据库环境变量。先备份并确定保留范围，再按当前 n8n 版本的官方迁移路径搬数据，最后逐项验收。如果不需要旧执行历史，可以评估只迁移必要业务数据；如果历史记录必须保留，先验证官方迁移方式，不要直接套用社区脚本。
适合 SQLite 实例已承担长期运行的独立开发者；需要保留团队工作流、凭据或成员权限的小团队维护者；以及准备升级 n8n 2.x、希望拆开数据库迁移与版本升级风险的负责人。
最后更新于 2026 年 10 月 31 日；数据库、CLI、执行数据与版本迁移信息核实自 n8n 官方文档，具体步骤仍须在计划使用的版本和测试实例中复核。
先按维护者需求决定迁移范围
SQLite 是自托管 n8n 的默认数据库，官方也提供 PostgreSQL 配置说明。数据库设置只决定实例连接哪个数据库，不会自动把 SQLite 文件里的数据复制过去；因此，把数据库类型改成 PostgreSQL 后看到空工作流，并不代表旧数据已经迁移。可先对照 n8n 官方数据库配置说明核实当前版本的连接方式。
| 维护者情况 | 先做什么 | 迁移选择与风险 |
|---|---|---|
| 个人试用、工作流少且不需要历史 | 核对当前 SQLite 备份是否可读，确认迁库的实际理由 | 暂时没有性能、维护或统一数据库需求时，继续使用 SQLite；若确定迁移，可在新库导入必要工作流和凭据 |
| 单人生产维护 | 列出工作流、凭据、用户配置、执行历史和文件数据 | 优先在空的 PostgreSQL 测试库验证官方实体迁移；不要把工作流 JSON 当作完整实例备份 |
| 小团队协作 | 在数据清单中增加用户、项目归属、共享与权限 | 先验证用户登录、项目可见范围和凭据使用，再决定是否切换；导入成功不代表团队关系符合预期 |
| 历史记录有审计或恢复价值 | 明确记录范围、关联数据及二进制文件是否必需 | 先测官方迁移路径和历史数据选项；若只能依赖社区脚本或手工转换，须单独标为非官方方案并完成恢复演练 |
若只是个人试用，迁移本身会新增备份、数据库维护和回退工作，暂时不换库可能更简单。若 n8n 已成为长期运行的平台，或团队要将数据存储统一到 PostgreSQL，则应先做测试迁移，再决定切换窗口；不要用“换库后更稳”代替真实的故障与容量评估。
按数据类型列出必须带走的内容
把“数据”拆成清单，避免只搬工作流 JSON 后才发现凭据无法解密，或成员看不到原项目。
- 工作流： 保存的工作流、草稿与已发布状态。导出时要确认拿到的是当前草稿还是已发布版本；导入后的启用状态也要核对。
- 凭据： 凭据记录及其加密密钥。优先确认源、目标实例使用的加密密钥是否一致；如采用明文凭据导出以处理密钥不同的问题，导出文件会暴露敏感信息，必须限制读写权限并在迁移后安全销毁临时文件。官方 CLI 支持工作流和凭据导入导出，也说明了相关命令和注意事项，详见 n8n CLI 文档。
- 用户与协作关系： 团队成员、项目、工作流归属、共享权限，以及团队是否能使用相关凭据。工作流共享与项目成员资格会影响用户实际可见和可执行的内容；不能假设导入几个工作流和凭据就恢复了原有协作关系。可按 官方工作流共享说明逐项核对权限。
- 执行历史： 它和工作流、凭据不是同一种业务对象。当前 CLI 的实体导出提供执行历史数据表选项，但该项默认不包含在导出中；选择包含后，仍需按版本验证记录关联、字段内容和恢复结果，不能把“命令完成”当作全部历史已完整迁移。
- 二进制数据： 图片、文档等文件数据可能位于实例文件系统或其他存储位置，不应只看数据库体积。n8n 将二进制数据作为独立存储事项说明，因此要按实际配置检查文件目录与读取能力，参阅官方二进制数据存储说明。
用决策条件选迁移路线
- 若实例只是试用，且没有需要保留的旧数据，选择继续使用 SQLite；等出现明确的长期维护、数据库统一或容量管理需求，再规划迁移。
- 若只需保留工作流和凭据，且目标 PostgreSQL 库为空，选择当前版本官方支持的导出、导入路径；先检查 ID 冲突和凭据密钥，再用测试实例验收。
- 若用户、项目和共享关系必须原样延续，先在副本上验证完整实体迁移与权限映射；若无法证明成员视野一致，先回退到仅测试，不切正式流量。
- 若必须保留执行历史，先测试官方实体导出中的历史数据选项，并抽样核验完整性与二进制关联；如果结果不完整或恢复路径未经验证，暂停迁移，不能用社区脚本直接覆盖生产库。
- 若迁库与 n8n 2.x 升级都在计划中，先迁库、后升级；分别完成验收，保留原 SQLite 副本和明确的回退条件。
这个分支的关键不是 PostgreSQL 是否“更适合生产”，而是迁移工具是否覆盖当前实例真正依赖的数据，以及团队能否在出错时回到可用状态。
在隔离副本上执行迁移与回退
下面步骤用于形成可验证的操作顺序，不替代当前版本的官方说明。特别是实体迁移命令的可用性、参数和所包含的数据类型，应先对照部署中的 n8n 版本复核。
- 冻结变更并记录现状。 选定维护窗口，暂停工作流编辑和会改变业务状态的自动化，记录实例版本、容器或进程配置、数据库路径、加密密钥的保管位置、工作流数量与关键项目归属。列出必须继续运行的定时任务和 Webhook。
- 备份源实例。 保存 SQLite 数据库及实际使用的配置、密钥和二进制文件；把工作流、凭据导出作为便于核对的额外副本，而不是完整备份的替代品。把备份放在实例之外，并实际确认文件可读取。
- 先迁移数据库，不同时升级版本。 在测试环境使用与源实例一致的 n8n 版本和单独的 PostgreSQL 空库。核对 PostgreSQL 连接设置，并确认目标数据库账号具备创建和修改 n8n 所用表结构的权限。
- 按选定范围导出并导入。 若需要跨数据库搬迁实体，可按当前 CLI 文档确认
export:entities与import:entities的用法；执行历史数据表需显式评估是否包含。官方说明要求目标库为空，且导入时可能会清理目标表，因此绝不能在不清楚目标库内容的情况下照抄命令。若只搬工作流与凭据，可使用相应 CLI 命令，但要核对 ID 冲突、草稿与发布版本、凭据加密密钥。 - 核对团队关系与业务数据。 用不同角色账号登录，检查项目、工作流归属、共享范围和凭据可用性；对执行历史则挑选不同状态的记录，检查显示内容与相关二进制文件。需要保留历史时，再做一次实际查询或业务端核验，不只对比导入前后的总数。
- 完成运行验收再切换。 逐项测试手动运行、定时触发、Webhook、失败通知、外部凭据调用和恢复需要；确认工作流状态与生产预期相符。记录切换后的监控观察项，保持旧 SQLite 副本不变，直到回退条件解除。
官方 v2.0 迁移报告用于查找升级前需要处理的工作流和实例配置问题，可在设置中的迁移报告查看；它是版本兼容性检查入口，不是 SQLite 到 PostgreSQL 的数据迁移证明。迁移数据库验收与 n8n 2.x 版本验收应分别记录，先查看官方 v2.0 迁移报告说明和官方 v2.0 破坏性变更说明。
按角色验收并核对存储边界
维护者先验收账号登录、工作流启停和凭据解密；团队负责人再验收每个角色能看到哪些项目与流程；业务负责人则抽查定时及 Webhook 触发、执行记录和失败处理。只要有一项权限或关键触发结果与原实例不一致，就先保持旧实例可恢复，不要把“页面能打开”作为迁移完成标准。
执行记录也会影响后续数据库增长。n8n 官方执行数据说明列出了历史修剪和数据保存设置；文档中的默认修剪条件包括按时间保留 14 天或执行数量达到 10,000 条，实际行为取先达到的条件。部署前应核对当前版本和实例配置，再根据审计需求调整，不能把默认值误认为团队已经确认的保留政策。(官方执行数据保留说明)
迁移后记录 PostgreSQL 实际占用、执行历史增长、二进制文件目录增长、备份副本位置及恢复演练结果。数据库切换不会自动提供高可用、异地备份或恢复保证；若 n8n 与 PostgreSQL 放在同一台服务器，单机故障也可能同时影响应用和数据库。需要独立控制数据与文件存储时，可先阅读本站的数据处理说明，再确定备份由谁执行、备份放在哪里以及怎样验证可恢复。
查看产品条件后再决定部署位置
如果当前运行在共享 VPS 上，迁移后的 PostgreSQL 与 n8n 可能仍受共享资源争抢、磁盘选择受限或存储与备份责任不清等因素影响；换成 PostgreSQL 并不会消除这些运维边界。若业务需要长期运行，并希望由单一租户掌握服务器上的应用和数据库，独享 AMD 物理服务器可以作为替代方案；但它同样不是自动备份或高可用服务，运维方仍需自行规划数据库备份、机外副本和恢复测试。
切换前，应先在 XFP Cloud 产品页核对当时实际可选的存储、系统、接入方式和计费周期，再决定是否将 n8n 与 PostgreSQL 部署在同一台机器上。若负载只是临时测试，或并不需要独享资源，继续使用现有实例通常更省事；若需要稳定长期运行的独享算力，再按真实数据增长与恢复要求评估服务器方案。
常见问题
换库后工作流和凭据会自动出现吗？
不会。PostgreSQL 环境变量只指定 n8n 连接哪个数据库，不会复制 SQLite 数据。需要按当前版本支持的迁移路径导入，并核验凭据加密密钥、工作流状态和 ID 冲突。
迁移时是否必须保留所有执行历史？
不一定。先确认审计、排错和恢复流程是否依赖旧记录；若不依赖，可评估只迁移必要业务数据。若必须保留，按官方 CLI 选项测试，并抽查关联记录和二进制数据，不要默认历史会随工作流一起导入。
团队用户和项目权限是否能随工作流一起迁移？
不能默认如此。导入工作流与凭据后，应分别检查用户登录、项目成员、工作流归属、共享关系及凭据调用权限。测试副本上的权限结果不一致时，不应切换生产实例。
n8n 2.x 升级能和数据库迁移一起做吗？
可以规划在同一维护周期，但应拆成两个变更并分别验收。先在源版本副本完成数据库迁移，再对迁移后的测试实例运行 2.x 迁移报告、处理兼容性问题；保留旧数据库副本，并为每一步写清回退条件。
常见问题
n8n 从 SQLite 换到 PostgreSQL，怎样迁移才不只是换了数据库？
先保留 SQLite 原始副本，再在与生产隔离的 PostgreSQL 空库上，使用当前版本官方 CLI 支持的实体导出与导入流程。迁移后要分别检查工作流、凭据解密、用户和项目关系、执行记录及二进制文件；确认目标实例能按预期运行后，才考虑切换正式流量。
只导入工作流和凭据，原来的 n8n 用户与项目权限会一起恢复吗？
不能默认会恢复。工作流和凭据导入能处理对应对象，但团队成员、项目归属、共享关系及角色权限需要按当前版本和实际部署方式单独核验。先在测试副本逐个账号登录，比较项目可见范围、工作流归属和凭据调用权限；不一致时不要把目标库直接投入生产。
n8n 数据库迁移时，执行历史要不要保留？
如果历史只用于日常排错，先检查保留策略和业务审计要求，通常可以评估只迁移当前业务所需的数据，避免把大体量历史一并搬迁。若历史属于审计或恢复依据，应在目标版本测试官方实体迁移选项，并抽查记录内容、关联工作流和二进制数据；不能仅凭导入命令成功就认定历史完整。
升级 n8n 2.x 前，怎么把版本升级风险和换数据库风险分开？
先在当前版本的隔离副本完成 SQLite 到 PostgreSQL 的迁移和验收，保留原库并记录回退条件；之后从已验证的 PostgreSQL 实例单独执行 n8n 2.x 兼容性检查与版本升级。这样一旦工作流行为、权限或登录出现问题，能区分是数据库迁移还是版本变化造成，而不是同时排查两类改动。