Troubleshooting n8n → PostgreSQL: Why Long LLM Texts Arrive Truncated or Corrupted

Problem overview

In self-hosted n8n setups, long text produced by an LLM and processed in a Code node can arrive at a PostgreSQL node with truncation, broken line breaks, or corrupted characters. This typically occurs during inter-workflow transfer or when the data is re-serialized for the database node.

Likely root causes

Common causes include: 1) Incorrect encoding conversions (UTF-8 vs. platform defaults) when stringifying and parsing JSON; 2) Truncation due to HTTP/webhook payload size limits or intermediary proxies (Railway limits, reverse proxies); 3) Database column types too small (varchar limit) or improper parameter binding; 4) Line-break normalization or CRLF issues introduced by Code node transformations; 5) Use of streaming/chunked payloads without proper reassembly.

Troubleshooting steps

1) Reproduce locally with logging: capture the exact payload leaving the Code node and arriving at the Postgres node. 2) Verify the database column is TEXT (or sufficiently large) and that parameterized inserts use the correct binary/UTF-8 encoding. 3) Base64-encode large blobs when passing between workflows to avoid serialization or newline mangling. 4) Check host/proxy limits and n8n webhook/body size settings; increase timeouts or payload caps if needed. 5) If workflows cross process boundaries, prefer stable IPC patterns (e.g., write to temporary storage and pass a reference) rather than embedding large strings.

Recommendations for production

Adopt defensive patterns: validate payload sizes, standardize UTF-8 handling across nodes, use chunking with checksums for very large artifacts, and include end-to-end logging. For critical data paths, implement retries and integrity checks (hashes) and consider storing large generative outputs in object storage with pointers in your database.