Fixing Truncated LLM Outputs in n8n → PostgreSQL Workflows

What happened

A user running n8n self-hosted on Railway generated multi-thousand-character Markdown in one workflow and handed it to a second workflow that writes to Postgres. The text arrived truncated and scrambled in the Postgres node. This pattern implicates the integration layer - serialization, encoding, transport limits, or node configuration - rather than the database itself.

Why it matters for businesses

Long-form LLM outputs are increasingly common in enterprise automation (summaries, policies, reports). If your orchestration or integration layer silently mangles large payloads, you risk data integrity loss, compliance gaps, incorrect downstream actions, and poor customer experiences. Such issues are magnified in automated pipelines where human inspection is limited.

Root causes and diagnostic steps

Check these in order: a) column/data type in Postgres (use TEXT or JSONB, not limited VARCHAR); b) n8n node and webhook payload limits (HTTP body size, proxy/gateway limits from Railway); c) encoding mismatches (ensure UTF-8 throughout and consistent content-type headers); d) intermediate serialization (JSON string length limits, base64 vs raw); e) transport truncation by queueing or IPC mechanisms; and f) driver/ORM settings that may chunk or escape incorrectly. Reproduce with a controlled payload and observe each handoff in logs.

Recommendations for leaders

Adopt explicit data contracts between nodes (schema, max sizes), implement robust logging/observability on each workflow handoff, and prefer file/object references (S3) for very large LLM outputs instead of in-memory payloads. Enable end-to-end UTF-8 handling and test upgrade paths for n8n and Postgres drivers. If adopting self-hosted orchestration, include automated integration tests for long-text artifacts in your CI pipeline to catch regressions early.