n8n + PostgreSQL

Same server is fine; same database is not a good idea. n8n creates and migrates its own tables on every upgrade, so keep them in a dedicated database and put the tables your workflows read and write in a second one on the same instance. Then give the Postgres credential your workflows use its own database user with rights only to that second database. A workflow with a buggy DELETE can then never touch n8n's credentials or workflow definitions, and you can back up, restore, or move the business data without taking n8n with it.

The encryption key. n8n stores credentials in PostgreSQL encrypted with a key that lives outside the database, either in the N8N_ENCRYPTION_KEY environment variable or in the config file n8n generates on first start. Restore the database without that key and every saved credential is unreadable, so each integration has to be reconnected by hand. Set the key explicitly as an environment variable, keep a copy with your database backups, and test a restore once before relying on it.

Execution history. n8n saves the input and output data of workflow runs in PostgreSQL, and a workflow that runs every minute or moves large payloads adds up quickly. Make sure pruning is enabled (EXECUTIONS_DATA_PRUNE) and set a retention window with EXECUTIONS_DATA_MAX_AGE, and consider EXECUTIONS_DATA_SAVE_ON_SUCCESS=none for high-frequency workflows, so only failed runs keep their data for debugging. On Neon this matters doubly, because storage is part of what you pay for once you leave the free plan.

Partly. On n8n Cloud, n8n keeps its own data on n8n's infrastructure, so PostgreSQL only plays its second role here: the database your workflows read and write. That database then has to be reachable from the internet, which makes Neon or another managed Postgres with SSL and an IP allowlist the practical pick rather than a database on a private server. You also give up the no-per-execution pricing, since Cloud plans are metered by workflow runs; the Pricing section has the tiers. Self-hosting remains the version of this stack where data never leaves your environment.

You move to queue mode: a main n8n process hands executions to separate worker processes through Redis, and all of them share the same PostgreSQL database. That is the setup the n8n Self-Hosted stack covers, with Redis as an add-on for exactly this step. Most teams never need it; a single instance on a modest server handles a steady stream of ordinary automations. The signs you've outgrown it are webhook responses slowing down while long workflows run, and executions queuing behind each other.