SQLite or PostgreSQL: when the switch is due

By default, n8n starts with SQLite, a file-based database without its own server process that requires no separate installation. This is sufficient for test instances, individual automations, and getting started. However, as soon as you run multiple concurrent workflow executions, use queue mode, or want to operate multiple main instances, n8n explicitly recommends PostgreSQL version 13 or higher in its own documentation. The right time to switch depends less on a fixed number of users than on three factors: the number of concurrent executions, the planned architecture, and how often locking errors already appear in the logs. As of: July 2026.

Signs that SQLite is reaching its limits

In the n8n community, one error pattern keeps recurring: SQLITE_BUSY: database is locked. The cause lies in the design of SQLite, which allows only one write access per file at a time. If several workflows run in parallel or you open the editor while executions are active, the write accesses to the same file collide. In the short term, WAL mode (Write-Ahead Logging) with a busy timeout of at least 5000 milliseconds helps, reducing the frequency of errors. However, the underlying single-writer limitation remains unaffected and reliably returns as load increases.

The thresholds that n8n itself names

In its documentation, n8n does not specify a fixed number of executions per day as the switching point, but ties the limit to concrete architecture decisions.

• Queue mode planned: For productive queue operation, n8n states directly that the execution mode queue with a SQLite database is not recommended. As soon as worker processes write to the same database in parallel, Postgres is needed.
• Multiple main instances (multi-main): For high availability with multiple main processes, n8n explicitly requires a connection to Postgres and Redis; SQLite is not intended for this.
• Worker concurrency: The concurrency value per worker is 10 by default; n8n recommends at least 5. According to the documentation, with many workers at low concurrency, exhausted database connections threaten, a condition that a single-file database without a real connection pool is structurally poorly equipped to absorb.
• Reference value from the benchmark: In the official performance tests, a single instance with a Postgres backend reaches up to 220 workflow executions per second. This is not an SQLite limit, but it shows the load class that Postgres is designed for in n8n.
• Signal from n8n Cloud: Even in its own cloud product, Postgres remains reserved for the Enterprise scaling plans; all smaller tiers run on SQLite. This roughly reflects when n8n itself considers the switch necessary.

Migration steps from SQLite to PostgreSQL

The switch is done via export and import, not via an automatic conversion of the database file.

• Prepare PostgreSQL: Provide Postgres 13 or newer, create a dedicated database and a dedicated user with full rights on it.
• Export workflows and credentials: Back them up via the CLI with n8n export:workflow --all --output=backup/ and n8n export:credentials --all --decrypted --output=backup/. The decrypted credentials backup must then immediately be placed in a protected location that is not publicly accessible.
• Switch environment variables: Set DB_TYPE to postgresdb and configure host, port, database name, user, password, and optionally the schema via the corresponding DB_POSTGRESDB variables.
• Start n8n against the empty Postgres database: n8n creates the required schema itself on first start; manually creating tables is not necessary.
• Restore the data: Import the saved states with n8n import:workflow --separate --input=backup/ and n8n import:credentials --separate --input=backup/ and then spot-check the workflows.

Effort and limits of the switch

The switch is not a one-click process but a small maintenance window: during export, reconfiguration, and import, n8n is briefly down, and detailed execution histories are not automatically migrated via the standard path. For small installations with few workflows, the effort is manageable; for grown instances with many active automations, testing beforehand on a staging instance is worthwhile. Anyone who does not want to take sole responsibility for this step during live operation can also have it accompanied externally, for example as part of an n8n consulting service at a fixed price.

Frequently asked questions about SQLite and PostgreSQL in n8n

From how many executions per day do I need to switch to PostgreSQL?

n8n does not give a blanket number. According to the documentation, the architecture is more decisive: as soon as queue mode or multiple main instances are planned, Postgres applies as a requirement, regardless of the exact execution volume.

Can I simply keep running SQLite and just increase the busy timeout?

For small instances with little parallelism, yes, this can noticeably reduce locking errors. However, as soon as you move toward queue mode or multi-main, this adjustment is no longer sufficient according to n8n.

Is data lost during the migration?

The standard path via export and import reliably transfers workflows and credentials. Complete execution histories are not automatically included; anyone who needs them should check this separately before the migration.

Do I necessarily need queue mode for PostgreSQL?

No. You can also use PostgreSQL in single-main operation without queue mode, for example to avoid locking errors. Queue mode and multi-main are separate expansion stages that additionally require Redis.

Further details on choosing the database and on the environment variables can be found in the n8n documentation on database selection as well as in the guide to queue mode.