PostgreSQL vs SQLite for n8n: Real world trade-offs

Why the database matters in n8n

At first glance n8n looks like a simple automation app. You drag nodes, connect APIs, and save workflows. But under the hood, n8n keeps a lot of state. Workflows, user accounts, execution logs, credentials, even pinned data – all of it goes into the database. Pick the wrong database and you hit limits early. Pick the right one and scaling is much smoother.

Out of the box n8n ships with SQLite. It is dead simple, file based, and needs no extra service. That makes it perfect for demos or one-off side projects. But if you are planning to run n8n on a VPS for production, SQLite will become a bottleneck fast. PostgreSQL is the recommended choice for real deployments. Let’s unpack why.

How SQLite works in n8n

SQLite is a serverless database. Instead of running as a daemon, it stores everything in a single .sqlite file. n8n connects directly to that file using local read/write operations.

Advantages of SQLite:

• Zero configuration, runs anywhere
• No network overhead, everything is local
• Fine for testing or a single small workflow

Limitations of SQLite:

• No concurrent writes: if multiple processes try to write, they block each other
• File corruption risk under heavy I/O
• Backups mean copying a large file, which may be inconsistent if the process is running
• Poor performance once execution logs grow into tens of thousands

In practice, SQLite is good for testing ideas, not for handling production webhooks or queues.

How PostgreSQL works in n8n

PostgreSQL is a client-server database. n8n connects over TCP to a running Postgres service. The database manages concurrency, transactions, indexes, and can scale across bigger workloads.

Advantages of PostgreSQL:

• Handles many concurrent reads and writes cleanly
• Strong data durability and crash recovery
• Easy to prune or archive old execution logs with SQL queries
• Extensions and tuning available (pg_partman, pgbouncer, etc)
• Reliable under queue mode with many workers writing simultaneously

Costs of PostgreSQL:

• Requires setup (container or package install)
• Consumes more memory than SQLite
• Needs proper backup strategy (pg_dump, replication, WAL archiving)

For production VPS hosting, the small overhead is worth it.

Performance differences

A quick comparison:

• Write throughput: SQLite locks the entire database file for each write. Postgres allows row level locks, so workers can write in parallel.
• History retention: In SQLite execution logs bloat the single file. Postgres can use partitioning or regular pruning to keep things lean.
• Scaling workers: Queue mode with Redis and multiple workers simply does not work reliably on SQLite. Postgres is required.

Benchmarks from users show SQLite can handle maybe a few hundred executions per day before performance degrades. Postgres can handle thousands per minute if tuned.

Migrating from SQLite to PostgreSQL

If you started with SQLite and want to move to PostgreSQL, here’s the cleanest way:

1. Install PostgreSQL: On your VPS run a container or install via your package manager.
2. Create a new database: createdb n8n createuser n8n --pwprompt
3. Export SQLite data:
   Use the built-in sqlite3 tool to dump the database: sqlite3 database.sqlite .dump > dump.sql But beware: schemas are not identical. Manual fixes are often required.
4. Run n8n fresh with Postgres: In your .env set: DB_TYPE=postgresdb DB_POSTGRESDB_HOST=postgres DB_POSTGRESDB_PORT=5432 DB_POSTGRESDB_DATABASE=n8n DB_POSTGRESDB_USER=n8n DB_POSTGRESDB_PASSWORD=yourpassword Then bring it up.
5. Recreate workflows manually if needed: For many users, it is faster to export workflows in JSON and reimport into a Postgres backed n8n.

Because SQLite and Postgres schemas differ, most production teams treat SQLite as disposable and start fresh with Postgres when moving to production.

Backup and restore differences

• SQLite: backup means copying the .sqlite file. This can be corrupted if copied during writes.
• Postgres: you can use pg_dump for logical backups, WAL archiving for continuous protection, or snapshots of the container volume.

In short, Postgres gives you safer, more consistent recovery options.

Best practices when using PostgreSQL for n8n

• Use at least Postgres 13 or higher.
• Keep it on NVMe storage for better I/O.
• Enable daily pg_dump plus weekly VPS snapshots.
• Set max connections carefully, especially if scaling workers.
• Prune execution data regularly (EXECUTIONS_DATA_PRUNE=true).

FAQ

Is SQLite ever ok for n8n?

Yes. Use it for local testing, tutorials, or very small side projects. For production, switch to Postgres.

Can I use MySQL or MariaDB instead of Postgres?

They are supported but not as well tested. Most of the community and docs assume Postgres.

How big does the database get in production?

It depends on how much history you keep. A busy setup with detailed execution logs can grow into tens of GBs quickly. Prune often.

Can I migrate from SQLite to Postgres without data loss?

Not always cleanly. Some schema mismatches exist. Often it is faster to export workflows and reimport into Postgres.

Is hosted Postgres an option?

Yes. Services like RDS or managed Postgres instances work fine. Just ensure latency to your n8n VPS is low.