n8n runs on SQLite out of the box, and for a five-minute test drive that’s exactly the right amount of database. The moment you’re running anything you’d be upset to lose, the calculation changes.
What SQLite actually is (and isn’t)
SQLite is a single-file, embedded database — there’s no separate database server, just a file n8n reads and writes directly. That’s what makes it perfect for trying n8n out: zero setup, nothing to configure, works immediately.
It’s also exactly what makes it a poor fit for production: a single file being written to by a single process handles concurrent access poorly, has no separate crash-recovery process, and turns “the file got corrupted” from a rare edge case into a real risk as write volume grows.
Where it actually breaks down
- Concurrent writes. As more workflows execute simultaneously, SQLite’s write-locking becomes a real bottleneck — and, in the worse case, a source of corruption under contention.
- Crash recovery. PostgreSQL is built to survive a hard crash mid-write without losing consistency. A single-file database has fewer guarantees.
- Support trajectory. n8n itself has been narrowing supported storage backends over time — MySQL and MariaDB support has already been deprecated, and the clear direction of travel is PostgreSQL as the one production-recommended option, with SQLite positioned explicitly for development and testing.
Why PostgreSQL is the actual production answer
PostgreSQL handles concurrent writes correctly, has mature backup tooling (pg_dump, WAL archiving for point-in-time recovery), and is what n8n’s own documentation and the wider self-hosting community converge on for anything beyond a demo. It’s also the database every serious backup and disaster recovery strategy for n8n assumes you’re running — the tooling and the guidance both expect Postgres underneath.
Migrating an existing SQLite instance
If you started on SQLite and it’s grown into something real, migrating isn’t exotic, but it’s not zero-effort either:
- Stand up a PostgreSQL instance (or use a managed Postgres offering).
- Point n8n’s environment configuration at the new database.
- Use n8n’s own data migration path to move existing workflows, credentials, and execution history across — this is the part worth testing on a copy first, not doing live.
- Verify workflows still run correctly against the new backend before decommissioning the SQLite file.
- Keep the old SQLite file around, untouched, until you’re confident the migration held.
The honest version of this advice: it’s meaningfully easier to start on PostgreSQL from day one than to migrate later, especially once execution history has grown large. If you’re setting up a new instance for anything beyond a quick test, skip SQLite entirely.
Why this matters more than it sounds
Database choice is the kind of decision that’s invisible when it’s right and very visible when it’s wrong — usually during an outage, not before one. It’s one of the specific requirements covered in our self-hosting requirements guide, and it’s handled by default on every managed instance: PostgreSQL from the start, with the backup discipline that assumes it.