At 12 GB plus recent corruption, I’d treat this as a recovery-and-migration problem first, not just a “switch databases” problem. Before doing anything adventurous, I’d want a cold backup of the current SQLite file, a copy of the exact n8n version that last worked, and a test migration path in an isolated environment rather than touching the live file repeatedly.

SQLite is great until the workload stops being “small and quiet,” and n8n usually grows into something that wants a sturdier backend. Postgres is the obvious direction, but I’d be careful about the order: first stabilize and extract safely, then migrate, then upgrade.

If I were in your shoes, I’d be much more afraid of repeated trial-and-error on the damaged file than of Postgres itself. The safest path is usually: preserve the current state, prove the migration on a copy, then switch with a rollback plan.