SQLite vs Postgres in n8n: Which Database to Use
I’ve seen n8n automations run flawlessly for weeks, then fall apart the moment concurrency and retention started to matter.
SQLite vs Postgres in n8n: Which Database to Use comes down to how much load, reliability, and scaling you need from your automation stack.
What n8n stores in its database (and why it matters)
n8n uses its database for workflows, credentials metadata, and execution history, so your database choice directly affects durability, performance, and how safely you can update or scale. By default, n8n uses SQLite, and it also supports PostgreSQL for self-hosted setups.
SQLite in n8n: where it shines
SQLite is a single-file database, which makes it fast to start and easy to run on a single host for development, demos, and low-traffic internal automations. It’s often the quickest way to validate a workflow idea, test webhook logic, and iterate without adding infrastructure.
Best-fit scenarios for SQLite
- You run n8n on one machine with one active instance.
- Your workflows are mostly scheduled jobs, light webhooks, or personal automations.
- You don’t need multiple workers, horizontal scaling, or high write concurrency.
- You want minimal operational overhead while you prove ROI.
SQLite’s real weakness (and how to work around it)
The practical limit you’ll hit is write concurrency. As workflows and executions increase, contention can show up as slowdowns, timeouts, or backlog during bursts (for example, multiple webhooks landing at once). If you must stay on SQLite longer, reduce execution retention, avoid running multiple n8n instances against the same file, and keep high-volume event ingestion out of n8n (buffer with your app layer or a queue) until you’re ready to move to Postgres.
Postgres in n8n: where it wins in production
Postgres is built for concurrent workloads, higher write throughput, and mature operational patterns (backups, replication, monitoring, connection pooling). If you’re running revenue-impacting automations—lead routing, customer lifecycle workflows, fulfillment triggers, billing events—Postgres tends to be the safer default.
Best-fit scenarios for Postgres
- You expect bursts (webhook spikes), multiple users, or heavier execution volume.
- You want queue mode with workers for better throughput and separation.
- You need consistent backups, restore testing, and clearer disaster recovery.
- You want the option to scale n8n beyond a single container or host.
Postgres’s real weakness (and how to work around it)
Postgres adds operational responsibility: provisioning, securing network access, managing credentials, and keeping backups verified. The workaround is to standardize it: use a dedicated Postgres instance, enforce least-privilege credentials, set backup/restore drills on a schedule, and keep your n8n database separate from application databases so automation changes don’t collide with product workloads.
Quick comparison table for fast decisions
| Decision factor | SQLite | Postgres |
|---|---|---|
| Setup speed | Fastest (file-based) | Slower (service + credentials) |
| Concurrency under bursts | Limited for concurrent writes | Strong with multiple connections |
| Scaling n8n (workers / multiple instances) | Not ideal | Designed for it |
| Backups & restore testing | Possible but easier to get wrong | Mature tooling and patterns |
| Failure recovery | Riskier if file/volume misconfigured | Clearer DR paths (snapshots, replicas) |
| Operational overhead | Low | Medium |
The hidden “gotcha”: Docker updates and the SQLite data path
When SQLite is used, losing data usually isn’t “SQLite corruption”—it’s almost always a deployment mistake: your n8n data folder wasn’t persisted, or environment variables weren’t set so n8n fell back to a default location. The fix is to make the SQLite path explicit and ensure the underlying volume is mounted and backed up as part of your server routine.
Production-ready configuration: SQLite (single instance)
If you’re intentionally using SQLite, lock the database file location to a persisted folder so updates don’t silently start fresh. Use the official n8n database environment variables reference to keep names correct as n8n evolves.
# n8n database (SQLite)
n8n database environment variables (official)
Production-ready configuration: Postgres (recommended for scaling)
For a stable production baseline, configure n8n to use Postgres with explicit host, port, database, user, and password values. Keep the database dedicated to n8n so retention policies, maintenance windows, and restore tests stay predictable.
# n8n database (Postgres)
n8n supported databases and settings (official)
Which one should you pick in the U.S. market reality?
If you’re shipping automations tied to U.S. revenue—lead capture, sales ops handoffs, customer onboarding, billing events, fulfillment triggers—choose Postgres early. The cost of one missed webhook burst or a broken restore during a launch is usually higher than the effort to run Postgres correctly.
If you’re validating workflows, building a personal automation hub, or running a single low-volume instance, SQLite is fine—just treat persistence and backups as non-negotiable so you don’t “accidentally” rebuild your automation history from scratch.
Common mistakes that force a painful migration later
- Starting on SQLite with no volume persistence: You update a container and your instance boots “empty.” Fix it by pinning the SQLite file path and mounting a persistent volume.
- Keeping too much execution history: Large execution tables slow everything down and bloat backups. Fix it by tuning retention in n8n and operationally scheduling cleanup if needed.
- Assuming Postgres is “set and forget”: Without tested restores, backups are just hope. Fix it by running restore drills into a staging environment.
- Changing the encryption key mid-flight: Credentials can become unreadable after migration attempts. Fix it by locking down your encryption key management before you move databases.
SQLite → Postgres migration: a safer, repeatable approach
n8n doesn’t treat database switching as a magic toggle where every internal record moves perfectly for you. The safer approach is to export what n8n can export cleanly, stand up Postgres, and re-import into a fresh instance while keeping your encryption key consistent.
1) Back up your current n8n data folder (especially if you’re on SQLite).
FAQ
Does n8n use SQLite by default, and is it “supported” long-term?
Yes—SQLite is the default when you don’t configure another database, and it remains a supported option. The long-term question isn’t support; it’s whether your workload will eventually demand higher concurrency, stronger operational tooling, and safer scaling patterns, where Postgres usually wins.
Will queue mode or multiple workers work well with SQLite?
SQLite is not a strong match for multi-instance or high-concurrency architectures because concurrent writes become a bottleneck. If you plan to separate webhook and worker processes or add workers for throughput, move to Postgres early so you don’t debug “random” backlogs that are actually database contention.
What’s the fastest sign you’ve outgrown SQLite in n8n?
You’ll feel it during bursts: webhooks slow down, executions pile up, and the UI starts lagging under load. If you see periodic stalls during peak traffic windows or when several workflows trigger at once, that’s your signal to migrate.
How do you avoid losing data when self-hosting n8n with SQLite?
Make the SQLite database location explicit and store it on a persistent volume that’s included in backups. Most “data loss” stories come from containers starting with a fresh default path after an update, not from SQLite randomly deleting records.
Is it okay to run Postgres on the same server as n8n?
For small production setups, it can be acceptable if the server has enough CPU/RAM and you isolate the database with proper access controls and backups. The key is to treat Postgres like a real production dependency: monitored, backed up, and regularly restore-tested.
Do you need to migrate immediately, or can you plan it later?
If your n8n instance is already tied to business-critical automations, plan the migration before your next growth jump. If it’s still a low-risk internal tool, you can delay—but only if you harden persistence and backups now so you’re not migrating after an incident.
Conclusion
Use SQLite when speed and simplicity matter more than concurrency and scaling, but treat persistence like production from day one. Choose Postgres when your n8n instance is part of a serious U.S.-market automation stack and you need predictable performance, safer scaling, and reliable recovery when things go wrong.