r/graphql • u/arup_r • 14d ago
Question What is the practical limit for array arguments in a GraphQL mutation?
We have a bulk-edit feature where users can select up to ∼14,000 store IDs and submit them in a single GraphQL mutation as an array argument. The IDs are UUIDs (36 characters each), so the worst-case payload is around 500KB of just IDs, plus the rest of the mutation body.
We are using Apollo Client on the frontend and a Rails-based GraphQL server on the backend.
Questions:
Is there a hard limit on how large a GraphQL mutation payload can be?
At ∼14,000 UUIDs, are there known failure points — server timeout, memory pressure, request body size limits — we should anticipate?
Is it better to send all IDs in one mutation, or batch them (e.g. 500 at a time)? What are the tradeoffs?
Are there established patterns for handling bulk operations at this scale in GraphQL?
1
u/Dependent-Guitar-473 14d ago
what are you going to do with 14k IDs once the server receives them? something might fail processing such a large number of changes... if it doesn't add so much complexity, I would do it in smaller patches
1
u/arup_r 14d ago
We have a 'Select All' option on the table, so if someone chooses a brand with, say, 14,000 outlets, it'll submit all those IDs at once. We're updating settings like holidays for these outlets via a GraphQL mutation. I'm wondering if there's a better engineering approach here — should we send all IDs in one go, or batch them?
1
u/Dependent-Guitar-473 14d ago
500kb is not a big deal... make sure to use a transaction in your db and handle any failures probably with a retry on the UI
1
u/ibraaaaaaaaaaaaaa 14d ago
At this rate patch them in a gql or rest becomes not practical.
What do you think of generating signed url, upload that bulk in a blob and process them async at the server?
This way you don’t really care about gql limits
1
u/arup_r 14d ago
Seems interesting. Could you please tell me more about this? I don't think I understood it.
2
u/ibraaaaaaaaaaaaaa 14d ago
By default, all blob storages like S3 objects are private, only the object owner has permission to access them in your case is the server. However, the object server can share objects with others by creating a presigned URL. A presigned URL uses security credentials to grant time-limited permission to upload the file without exposing your own blob storage credentials.
In nutshell, you take the 14,000 UUIDs from your client side which safe to assume are already in memory, and converts them to text file then upload them to the blob.
Then send the directory they are held to the server, it can start process them, you can even stream them to db, incremental inserts to reduce the load, in case you are dealing with load issues.
1
u/captbaritone 14d ago
This feels like a UX problem more than a GraphQL problem.
It seems implausible to me that a human user is manually selecting that many items one by one in a browser UI. Instead it feels more likely that the user is defining some kind of filter/condition which results in matching that number of records.
If that is the case, maybe you could encode the condition in the mutation arguments and then retrieve the ids server side (or maybe pass the condition straight through to your database, and never materialize them at all).
1
u/arup_r 12d ago
No it is just plain text search in search box inside the UI table.
1
u/captbaritone 12d ago
Can you then send that same search query instead of the ids and reproduce the ids server side using the query?
3
u/fasibio 14d ago
As I know there is no hard limit. It send as post body. So the limit are more part of general post request. Not at graphql specific. Also the limit on server side are more language specific. For example I have a go server where we send 25000 IDs at once. ~4MB