Recent reductions to GraphQL Admin API query costs prompted questions about how costs are now calculated. The current documentation says cost equals the maximum of possible fields selected and recommends running queries to find true cost.
A developer reports that this no longer matches observed behavior. Through data analysis, they believe connection costs are now weighted by a logarithmic function: log(maximum selected fields) divided by log(e^0.5), implying a scaled, non-linear cost for connections (paginated lists/edges).
They argue that requiring live queries to discover costs is impractical when rules change, since it forces re-evaluating all queries and adjusting point budgets. They built a cost prediction tool using the graphql-tag package and asked why such estimation isn’t built into the official client.
Shopify support referenced the existing rate limit documentation and requested more context on the use case. They committed to forwarding feedback to product teams for clearer documentation and potential tooling improvements.
Outcome: No confirmation of the proposed formula and no documentation change yet. Discussion remains open pending product team review and more use-case details.
Hello,
First of all I am glad that the costs of the GraphQL have been reduced.
But I was wondering how the costs where calculated at all now.
Via datamining i found out that connection costs are now weighted by log of base e^0.5.
Is there any documentation of that? Can the documentation be updated to reflect that?
It is quite tedious to figure out all the changes..
Hey @Jan-S , thanks for sharing this.
Currently, our documentation is limited to what we have available here: https://shopify.dev/docs/api/usage/rate-limits#cost-calculation and it’s mentioned that “The cost of a query is the maximum of possible fields selected. Running a query is the best way to find out its true cost” which looks like what you have been doing.
I would love to pass on your feedback to our product teams to get a better understanding of what’s missing, along with a little more context on how you’re using this information (as you mentioned it’s quite tedious). If you could share a little bit more about your use case and the need for more clear documentation, that would really help me present this best!
Kind Regards,
Well, this is not true anymore.
The cost is calculated with “the maximum of possible fields selected” but it is not “the maximum of possible fields selected” but
log(“the maximum of possible fields selected”) / log(e^0,5)
Also this is just an opinion, but running a query to look how mutch it MAY cost is kind of problematic for me.
Especialy IF the rules change like recently. Because now you need to check your entire code, run all the queries again and change all the points.
I build a small tool based on the “graphql-tag” package that was able to predict the cost of a query.
Why is this not part of the GQL client?
Hey @Jan-S ,
Thanks for sharing that. I’ve passed this feedback on to our product teams to consider making this more clear.
Thanks,
Kyle G.