Gestionar grandes cargas de datos

Preguntas
1

Hola, tengo un flujo de trabajo que recibe grandes cargas JSON de una API, a veces con miles de registros con objetos anidados.
El flujo de trabajo funciona bien con solicitudes más pequeñas, pero a medida que crece la carga útil, el uso de memoria aumenta significativamente y los workers pueden volverse inestables.
Estoy considerando almacenar primero la carga útil sin procesar en PostgreSQL o almacenamiento de objetos, y luego procesarla en fragmentos más pequeños en lugar de mantener todo dentro de la ejecución de n8n.
¿Normalmente transmitirías/procesarías los datos en lotes, o almacenarías primero la carga útil y dejarías que flujos de trabajo separados la procesen?
Además, ¿cómo decides cuándo una carga útil es lo suficientemente grande como para no pasarla a través de todo el flujo de trabajo?

Describe el problema/error/pregunta

¿Cuál es el mensaje de error (si es que hay alguno)?

Por favor, comparte tu flujo de trabajo

(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)

Comparte el resultado devuelto por el último nodo

Información sobre tu configuración de n8n

  • Versión de n8n:
  • Base de datos (predeterminada: SQLite):
  • Configuración n8n EXECUTIONS_PROCESS (predeterminada: own, main):
  • Ejecutando n8n mediante (Docker, npm, n8n cloud, aplicación de escritorio):
  • Sistema operativo:
2

Hola @Ethan_Mitchell, mientras esperas una respuesta, aquí hay algunas cosas que podrían ayudarte:

Recursos sugeridos

Coincidencia automática con tu pregunta.

Documentación:

Foro:

@Niffzy - has ayudado con problemas similares antes, ¿puedes echarle un vistazo?

Sugerido automáticamente por el bot de la comunidad de n8n. Es una prueba piloto - comparte tu opinión aquí.

3

Hola @Ethan_Mitchell Almacena primero, luego procesa en lotes. Eso es lo que recomiendan los documentos de memoria de n8n.

  1. Ingesta: Webhook → guarda el payload sin procesar en Postgres/S3 → responde 200. Luego inicia el procesador con Execute Workflow (“Wait for Sub-Workflow Completion” desactivado), o haz que un trigger de Schedule recoja los payloads pendientes.
  2. Procesador: lee 200–500 registros a la vez y pasa cada lote a un sub-flujo que devuelve solo un resultado pequeño. Su memoria se libera después de cada lote.

3. Desactiva “Save successful executions” en el procesador.

Regla general: si supera unos pocos MB o unos pocos miles de elementos, almacénalo y pasa un ID en su lugar. Cada nodo mantiene su propia copia de los datos.

5

Hola @Ethan_Mitchell, la búsqueda también tiene que ocurrir dentro del flujo de trabajo por lotes. La paginación integrada de HTTP Request recopila las páginas antes de devolverlas, por lo que agregar Loop Over Items después no elimina ese costo de memoria inicial.

Pasa un cursor a un subflujo de trabajo, obtén una página con la paginación automática desactivada, procésala/guárdala y devuelve solo el siguiente cursor y un recuento. Mantén Wait for Sub-Workflow Completion activado en el bucle principal para que los lotes no se acumulen.

Si la API solo devuelve una respuesta JSON enorme, divídela ascendentemente en objetos más pequeños o filas de base de datos. Guardarla en S3 después de que n8n la haya analizado no evitará ese primer pico de memoria.

No hay un corte universal de MB o recuento de registros. Prueba cargas útiles anidadas representativas en el entorno de ensayo con tu concurrencia esperada, mide el RAM pico del trabajador y elige un tamaño de lote que deje espacio libre por debajo del límite del trabajador.

6

Para cargas útiles grandes, el patrón de producción más seguro es:

Almacenar primero → procesar en lotes

Enfoque recomendado

1. Webhook / Solicitud HTTP recibe la carga útil

2. Almacenar inmediatamente la carga útil sin procesar (PostgreSQL jsonb o S3/MinIO/almacenamiento de objetos)

3. Devolver un rápido 200 OK al llamador

4. Iniciar un flujo de trabajo de procesamiento separado (o el mismo flujo de trabajo en un paso posterior) que:

•  Leer la carga útil en fragmentos

•  Procesar con **Dividir en lotes** (p. ej., 50–200 registros a la vez)

•  Realizar el trabajo real