Short answer: Use Data Store for small workflow-owned records and simple lookups. Use PostgreSQL when you need relational queries, reporting, stronger ownership boundaries, or access from more than one system.

When is Data Store enough?

Data Store fits a modest key-value or record list used by an automation. Examples include a processed-event marker, a small routing table, or a workflow-owned cache. Keep the record shape simple and define how old entries are removed.

Do not treat a small store as a general analytics database. Large scans, joins, and frequent concurrent writes are signs that the data has outgrown the workflow boundary.

When should PostgreSQL be the source of truth?

Use PostgreSQL when records relate to one another or need SQL filters, indexes, transactions, and reporting. It also fits data that must be shared by several workflows or by an application outside n8n.

Define ownership before connecting the node. The workflow should know which table it may write, which columns are required, and which failure should stop the run.

How do retention and recovery differ?

Data Store cleanup is part of the workflow or its operating routine. PostgreSQL cleanup can use database policies, scheduled jobs, and backups. In both cases, record the retention rule in the workflow documentation.

Test a restore or rebuild path before the data becomes critical. A backup that cannot be read by the workflow is not a complete recovery plan.

What should a migration check include?

Count the source records. Compare required fields and types. Load a small sample. Run the read and write paths. Then compare counts again and verify that duplicate keys are handled.

For node-level options, see the database node reference. For backups and migration order, use the backup and restore guide.