2026 n8n SQLite to PostgreSQL: How to Preserve Workflows?

Do not treat changing the database settings as a migration: back up the instance, define which data must survive, use the migration path documented for the current n8n version, and test each required function before switching production. This approach suits a planned database change; it does not make an unsupported method for copying execution history safe.

Suitable: A self-hosted instance has become a long-running service, or a team needs a controlled database change.
Not suitable: A short-lived test instance has no data worth keeping; in that case, a clean PostgreSQL setup may be simpler than preserving disposable state.

Independent developers can use this guide to decide whether their SQLite instance needs to move at all.
Small-team maintainers can use it to check workflows, credentials, and access relationships.
Upgrade owners can separate database migration checks from an n8n version upgrade.

Last updated October 31, 2026. Checked against the n8n database configuration, CLI documentation, and official n8n 2.0 migration and change notes.

Start with the decision: keep SQLite or move to PostgreSQL?

n8n documents SQLite as its default database and also documents PostgreSQL configuration. That confirms both are supported options; it does not mean that pointing a running instance at a new PostgreSQL database copies its SQLite contents. Database configuration and data migration are separate tasks. Check the supported database settings for the target version before changing deployment variables.

Use these conditions to choose a path:

• Keep SQLite for now if the instance is for personal testing, its data is easy to recreate, and there is no operational reason to change. Still make a backup before an n8n upgrade or deployment change.
• Move to PostgreSQL if the instance is a maintained service and the team has a clear reason to change databases, such as aligning with its existing database operations. Decide first which records and relationships are actually required.
• Create a fresh PostgreSQL-backed instance and import selected business data if old execution history and other historical state are not needed. This avoids assuming that every piece of the old database has a supported transfer path.
• Pause the change and test a copy if execution history, user access, project membership, or binary data must be preserved and the applicable documentation does not confirm the migration route.

This is the core n8n SQLite-to-PostgreSQL migration decision: preserve what is required using a verified method, not by changing settings and hoping the old database appears in the new one.

First, identify which maintainer profile applies

The database is only one part of an n8n deployment. The correct migration scope depends on who needs the instance to work afterward.

A trial installation and a production service should not be treated alike. A trial can often be rebuilt around the workflows that still matter. A production instance may depend on saved credentials, scheduled triggers, incoming webhooks, execution records, and relationships between users and shared workflows.

For team setups, importing workflow definitions alone does not prove that the intended collaborators can see or run them. n8n’s workflow-sharing documentation describes sharing behavior, but the migration owner still needs to verify the result in the actual target instance.

Check what must survive before exporting anything

List the required data by type. Do not assume that a workflow export contains every item stored or referenced by an installation.

• Workflows: Identify the active workflows and record their IDs, names, owners, and current enabled state. The n8n CLI documentation covers workflow import and export. Review the relevant options for the installed version before running them.
• Credentials: Record which credentials each required workflow uses. Export and import them using the documented CLI workflow, and protect the resulting files as secrets. Confirm that the target instance can decrypt and use them.
• Encryption key: Find the configured credential encryption key and ensure the target instance uses the correct key where the migration method requires it. Do not treat the key as an ordinary environment setting: losing it can prevent access to stored credentials. Keep it in an appropriately protected secret store, not in a ticket or shared notes.
• Users, projects, and sharing: Identify which people need access and which workflows or credentials are shared. Do not infer that importing workflows and credentials recreates these relationships. Validate them separately against the current version’s supported behavior.
• Execution history: Decide whether old runs are needed for audit, debugging, or business records. n8n documents execution-data configuration and retention separately from workflow and credential handling. A normal workflow import is not evidence that past runs have been transferred.
• Binary data: Check whether workflows rely on files or other binary payloads. n8n documents binary-data storage separately; confirm where this data lives in the current deployment and what the proposed migration method does with it.

The n8n CLI reference confirms import and export commands for workflows and credentials, and includes cautions around IDs. Before importing, review whether matching IDs could replace or conflict with records in the target instance. Test that behavior with a disposable copy rather than learning it during production cutover.

For solo maintainers: choose between a clean start and selective import

A solo maintainer often has fewer access relationships to restore, but still needs to distinguish required business data from incidental state. The key question is not simply whether the old database can be copied. It is whether the target instance will contain every item needed to run the selected workflows safely.

If old executions are unnecessary, first check whether a clean PostgreSQL-backed instance plus documented workflow and credential imports covers the requirement. That route can avoid carrying historical data that has no operational use. It still needs a backup, careful handling of the encryption key, and a test of all required triggers and integrations.

If existing execution history or other internal state is essential, do not assume the CLI’s workflow and credential import/export support covers it. Check the official documentation for the exact n8n version and deployment method. If the documentation does not establish a supported route for the data in question, treat a community script or manual database conversion as an unverified method—not as an official migration procedure.

Before cutover, prepare a short inventory with one row per required workflow: its owner, credentials, trigger type, external dependencies, and the validation action that will prove it works. This makes the acceptance test concrete rather than relying on a workflow count.

For small teams: verify access, ownership, and sharing

A team can appear to have a successful migration while users have lost access to the workflows they need. Imported workflow definitions do not, by themselves, prove that user, project, or sharing relationships have been reproduced.

Start by listing the people who need access and the workflows they should be able to view, edit, or run. Include any shared credentials that the workflows depend on. Use the current version’s official documentation to establish which parts of that relationship can be migrated through the method being considered. The sharing guide is useful for understanding the intended access model, but it is not a substitute for checking the target instance.

On a test copy, sign in with representative accounts. Compare what each account can see and do before and after migration. Check workflow ownership, shared access, and whether a workflow can use the credentials it is supposed to use. Record any differences and resolve them before the production switch.

For teams upgrading to n8n 2.x, keep version behavior as a separate line of investigation. Review the official 2.0 breaking changes and v2 migration report for changes and migration guidance relevant to the target version. Do not assume that an example from another version or a community report applies to the team’s installation.

For teams that need execution history: verify the method first

Execution records are not the same migration object as workflows or credentials. A team that needs the old runs should confirm, before scheduling a cutover, whether the current official path supports transferring the required history and associated data.

n8n’s execution-data guidance explains execution-data configuration and retention. Use it to establish what the source instance retains and what the team actually needs to preserve. It does not establish that the regular workflow and credential import process transfers every execution record.

If a proposed method uses a community script or manual database transformations, label it as non-official unless n8n’s current documentation says otherwise. Test it on a copy and inspect more than whether a few records appear: check that required records are complete, readable, associated with the expected workflows, and recoverable from the planned backup. Also check whether the destination has sufficient storage for the records and any associated binary data. Do not promise that a script will preserve history until this has been demonstrated for the exact source and target versions.

Follow a controlled migration and acceptance sequence

Use the following sequence for n8n database migration. It keeps the data decision, database change, and version upgrade from becoming one untestable operation.

• [ ] Record the source state. Note the n8n version, deployment method, database settings, required workflows, credential dependencies, access relationships, execution-history needs, and binary-data storage arrangement.
• [ ] Read the documentation for the target version. Check PostgreSQL configuration, CLI import/export behavior, relevant sharing and execution-data guidance, and any version migration notes. Confirm that every planned command and setting applies to the installed and target versions.
• [ ] Back up and verify the backup. Preserve the SQLite database and deployment configuration. Protect credential exports and encryption material. Confirm that the files can be read and that the team knows how to restore the source instance.
• [ ] Build a test destination. Use a separate PostgreSQL-backed instance or other isolated test environment. Do not point production at an empty database and expect it to discover or copy the SQLite database.
• [ ] Import only through the selected, documented path. Review ID collision or overwrite risks before importing workflows. Handle credentials securely and confirm the target can use them. Treat any additional transformation as a separately tested method.
• [ ] Run role-based acceptance checks. Confirm login, workflow visibility, ownership, credential use, and the behavior of required schedules and webhooks. Check execution records and binary data only to the extent they are part of the agreed migration scope.
• [ ] Set a cutover and rollback condition. Switch production only after the required tests pass. Keep the original database and a clear restoration plan until the target has been accepted. If required workflows, permissions, or records are missing, return to the source rather than treating a partial import as complete.

During validation, test real dependencies safely. A workflow can be enabled in the target and still fail because a credential is unavailable, a webhook endpoint has changed, or a user lacks the necessary access. Use test endpoints or controlled inputs where possible, and avoid triggering external actions that could create duplicate business operations.

Check storage and operating conditions after the data scope is known

Only estimate storage after the team has decided what to retain. The PostgreSQL database, execution history, binary data, logs, and backups have different growth and recovery needs. A move to PostgreSQL does not automatically provide high availability, an external backup, or a recovery guarantee.

Estimate from the current installation rather than a generic threshold. Record the database size, the volume of binary data, the execution retention policy, and the space needed for the backup and any temporary migration copy. Then decide whether n8n and PostgreSQL should share a host or use separate infrastructure. That choice depends on operational requirements and measured storage growth, not on the database switch alone.

For a long-running self-hosted n8n service, a dedicated physical server may be worth evaluating when predictable access to the host and sustained storage capacity matter. It is not automatically the right choice for a disposable test deployment, a very light workload, or a setup that needs rapid elastic scaling. XFP Cloud’s available server options and billing terms can be checked against the actual storage, operating-system, and billing requirements before deciding. Neither a server rental nor PostgreSQL should be described as a migration service or backup service unless those capabilities are explicitly provided.

The migration decision should therefore be based on the data that must survive, not on a belief that PostgreSQL itself preserves the SQLite instance. If the source is a shared VPS or cloud instance, factor in any limits on storage control, database placement, or access to the underlying host; if those limits obstruct the required operating model, compare them with an independently managed AMD physical server. XFP Cloud is a more suitable option when the workload needs a dedicated machine for sustained operation, provided the listed storage and operating-system options match the deployment plan.

Before selecting a host, use the current XFP Cloud product listing to verify available NVMe options, supported systems, access method, and billing cycle. Then choose whether PostgreSQL and n8n belong on the same server based on the tested data scope, backup plan, and recovery requirements—not on the assumption that a database change alone makes the service resilient.