This only applies for on premise orchestrator.
We have orchestrator in the cloud, but we did get a response from tech support stating that we should not store such quantity of data in a queue item and rather have a link to acquire that data from something else instead.
I’ll not question the reasons why you would add so much data to your queue items as transactional fields.
I agree with the top response text: if you need more, store it in an external location (a txt file, excelfile, whatever) and refer to that file with a specificcontent value of just a few bytes.
All that data for each item will fill up your database, and will hinder your platforms performance over time, for something that you need only for one transaction at one time.
Our (attempt at) best practice is to keep the # of activities in a dispatcher component as low as possible, and the amount of data stored in a queue as low as possible. Often, just storing the reference to an order, ticker or document, and then runtime, access the blobs of data further required only during your process/perform phase, to be discarded directly after.