Por qué crece la base de datos de n8n: limpiar los datos de ejecución

Con cada ejecución de un workflow, n8n almacena datos de ejecución en su propia base de datos, y sin limpieza, esta base de datos suele crecer rápidamente hasta varios gigabytes en workflows activos. La solución se llama Execution Data Pruning: n8n elimina automáticamente las executions completadas en cuanto superan un número determinado de horas o el número total de executions almacenadas supera un límite. Este comportamiento se controla mediante variables de entorno como EXECUTIONS_DATA_PRUNE, EXECUTIONS_DATA_MAX_AGE y EXECUTIONS_DATA_PRUNE_MAX_COUNT, que en instancias de n8n autoalojadas se establecen directamente en la configuración. Actualizado: julio de 2026.

¿Por qué crece tan rápido la base de datos de n8n debido a las executions?

Cada ejecución de un workflow genera un registro con el input, el output y el estado de cada nodo individual, y con varios cientos de ejecuciones al día esto se convierte rápidamente en un volumen de datos considerable. Por defecto, n8n almacena tanto las ejecuciones exitosas como las fallidas de los workflows publicados, así como las pruebas manuales realizadas desde el editor. Quien opere muchos workflows con una frecuencia de disparo alta, por ejemplo sincronizaciones horarias o procesos impulsados por webhooks, nota este crecimiento especialmente en los tiempos de carga de la lista de executions y en el tamaño del archivo de la base de datos. Según la documentación oficial de n8n, el pruning está por ello activado por defecto para que la base de datos no crezca de forma descontrolada.

¿Qué hace exactamente el ajuste EXECUTIONS_DATA_PRUNE?

EXECUTIONS_DATA_PRUNE es un interruptor booleano con el valor predeterminado true, que determina si n8n elimina automáticamente las executions completadas. Si la variable está activa, n8n primero marca las executions antiguas para su eliminación (soft delete) y después las elimina definitivamente (hard delete). Según la documentación, este proceso de dos etapas favorece el rendimiento, ya que la eliminación real se realiza en segundo plano sin bloquear el funcionamiento en curso. Los detalles del proceso exacto se describen en la documentación de n8n sobre la gestión de datos de ejecución.

¿Qué variables de entorno determinan cuánto tiempo se conservan los datos?

El pruning se activa en cuanto se cumple una de dos condiciones: la antigüedad de una execution supera un límite, o el número total de executions almacenadas supera un límite. Las variables relevantes están documentadas en la referencia de executions.

• EXECUTIONS_DATA_MAX_AGE: antigüedad en horas a partir de la cual una execution completada se marca para su eliminación, valor predeterminado 336 horas, es decir, 14 días.
• EXECUTIONS_DATA_PRUNE_MAX_COUNT: número máximo de executions que deben permanecer en la base de datos, valor predeterminado 10.000, el valor 0 significa sin límite.
• EXECUTIONS_DATA_HARD_DELETE_BUFFER: margen de seguridad en horas, valor predeterminado 1, que excluye deliberadamente los datos completados muy recientemente de la eliminación definitiva para que sigan disponibles para la resolución de problemas.
• EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL / EXECUTIONS_DATA_PRUNE_SOFT_DELETE_INTERVAL: con qué frecuencia, en minutos, se inicia cada ejecución de eliminación, valores predeterminados 15 y 60 minutos respectivamente.

Para SQLite como base de datos, la documentación ofrece una advertencia importante adicional: el espacio en disco liberado por el pruning es reutilizado internamente por SQLite, pero no se devuelve automáticamente al sistema operativo. Para liberar realmente el espacio en disco, n8n recomienda establecer la variable de entorno DB_SQLITE_VACUUM_ON_STARTUP o ejecutar manualmente el comando VACUUM.

¿Qué executions nunca se eliminan automáticamente?

No todas las executions están sujetas a la limpieza. Según la documentación, las executions con el estado new, running o waiting están excluidas de la eliminación porque aún no han finalizado. Además, las executions anotadas, es decir, aquellas a las que se les han asignado etiquetas o una valoración en el editor, se conservan de forma permanente. Esto resulta práctico para proteger de forma selectiva pruebas importantes concretas o errores llamativos de la eliminación automática, sin desactivar todo el pruning.

¿Cómo se define por workflow qué se almacena realmente?

Antes de que el pruning entre siquiera en juego, el ajuste del workflow decide si se almacena una execution. En el editor de workflows, esto se hace abriendo el punto Settings a través del menú de tres puntos en la esquina superior derecha, donde se define por separado si deben almacenarse las executions fallidas, exitosas y manuales. Además, la opción Save execution progress controla si n8n guarda el estado de cada nodo individual durante la ejecución, lo que según la documentación puede aumentar la latencia, pero a cambio permite reiniciar en el punto del error. Para workflows productivos con un volumen alto, merece la pena comprobar exactamente qué executions son realmente relevantes a largo plazo antes de ajustar las variables globales de pruning. En la automatización con n8n de NordFlux, esta configuración forma parte de la puesta en marcha básica del lado del servidor, para que la base de datos de un sistema autoalojado se mantenga siempre eficiente y la soberanía de los datos permanezca en manos del cliente.

Preguntas frecuentes sobre n8n Execution Data Pruning

¿Qué ocurre si desactivo EXECUTIONS_DATA_PRUNE?

Si la variable está en false, n8n deja de eliminar automáticamente las executions y la base de datos sigue creciendo sin límite. Esto puede ser útil para fases de prueba cortas o depuración, pero es arriesgado en funcionamiento continuo, porque el archivo de la base de datos acabará llevando el rendimiento y el espacio en disco a sus límites. Para instancias productivas, se recomienda dejar el pruning activado y ajustar en su lugar EXECUTIONS_DATA_MAX_AGE y EXECUTIONS_DATA_PRUNE_MAX_COUNT a las propias necesidades.

¿Qué tan rápido desaparecen realmente de la base de datos las executions completadas tras alcanzar el límite de pruning?

Esto depende de los intervalos configurados: por defecto, n8n comprueba los candidatos a soft delete cada 60 minutos y ejecuta el hard delete definitivo cada 15 minutos. Además, el margen de hard delete, de una hora por defecto, garantiza que las executions completadas muy recientemente no desaparezcan de inmediato. En la práctica, según la configuración, puede tardar hasta unas pocas horas antes de que una execution abandone realmente la base de datos.

¿Puedo proteger executions individuales importantes de la eliminación automática?

Sí, las executions anotadas, es decir, aquellas con etiquetas o una valoración en el editor de n8n, están excluidas de la limpieza automática según la documentación. Esto resulta adecuado para mantener trazables de forma permanente casos de error llamativos concretos o ejecuciones de referencia, sin desactivar el pruning global. Para la gran mayoría de las executions rutinarias, la eliminación automática sigue no obstante activa.

¿Tengo que hacer algo más manualmente con SQLite después del pruning?

Sí, porque SQLite no devuelve automáticamente el espacio en disco eliminado al sistema operativo, sino que sigue utilizándolo internamente para futuras executions. Quien quiera reducir realmente el espacio en disco utilizado debería, según la documentación de n8n, establecer DB_SQLITE_VACUUM_ON_STARTUP o ejecutar ocasionalmente el comando VACUUM de forma manual. Con PostgreSQL como base de datos, este problema suele presentarse de forma menos acusada, ya que su gestión del almacenamiento funciona de otra manera.