Currently n8n stores all data it generates in the same database, from workflows to credentials and from tags to workflow executions. The last is the thing my feature request is about. Due to a self-hosted n8n instance handling tens of workflow runs per second, my database is generating a significant amount of data. For the sake of redundancy, I outsource my database hosting to a third-party to ensure that my hundreds of created workflows cannot be lost in the event of hardware failure. The problem I’ve been encountering for the last few months is that I’m getting high charges caused by the lots of transactions and storage consumed by workflow executions stored in the execution_entity table.
That’s why I’d like to suggest the ability to separate the storage location for the execution_entity table. With that option, I can store this execution data in a self hosted database while continuing to store all other important n8n data in a redundant database. One idea I had is (optional) extra environmental variables in addition to the default ones used to configure the database n8n uses. So instead of DB_POSTGRESDB_HOST there’ll be DB_POSTGRESDB_HOST_EXECUTION_ENTITY to provide a different database.