September 16, 2026 · 5 min read · Kilat Labs

Shopify metafieldsSet: flat cost vs dynamic

Shopify's metafieldsSet mutation stopped costing a flat 10 points on September 15, and the same 25 metafields now cost 14 or 260 points depending on owners.

Shopify changed what metafieldsSet costs on September 15, 2026, and the change is not a rate-limit tweak. It is a pricing signal about how you shape your data. The mutation used to cost a flat 10 points no matter what it touched. It now costs 10 plus a weight for every distinct resource whose metafields you changed, and orders are weighted ten times heavier than variants. If you run a nightly ERP or PIM sync against Shopify Plus, the same 25 metafields can now cost you 14 points or 260 depending only on how they are spread across owners.

What changed on September 15, 2026

The metafieldsSet mutation in the Admin GraphQL API moved from a flat cost to a dynamic one, effective the day it was announced. Shopify's changelog entry sets the new cost at a base of 10 points, plus the number of distinct owners of each type multiplied by that type's weight. The weights are published: Order counts 10, Product counts 4, ProductVariant counts 2, and Collection, Customer and Shop count 1 each. Every other owner type counts 0, so writes against those still land at the base 10.

Two caps bound the damage. A single invocation cannot exceed 260 points, which is what you get from 25 distinct orders. And the mutation still accepts at most 25 metafields per call, unchanged. There is no version gate mentioned and no migration window. The old flat rate is gone.

Flat cost vs dynamic cost, in numbers

The spread between the cheapest and most expensive way to write 25 metafields is now roughly 18x, and it depends entirely on owner distribution. Write 25 metafields onto a single product and you pay 10 plus one distinct Product at weight 4, so 14 points. Write 25 metafields across 25 separate orders and you pay 10 plus 25 orders at weight 10, so 260 points. Identical mutation, identical metafield count, identical payload size. The only variable is how many distinct owners you touched and what type they are.

Variants sit in the middle and they are where most catalog work lives. Twenty-five metafields across 25 distinct variants costs 10 plus 50, so 60 points. That is four times the single-product case and less than a quarter of the order case.

Put that against the plan buckets. Shopify documents the GraphQL Admin API restore rate at 100 points per second on standard plans, 200 on Advanced, 1,000 on Plus and 2,000 on enterprise, with a hard ceiling of 1,000 points for any single query. A 260-point call is a quarter of a second of Plus budget and 2.6 seconds of standard-plan budget. Run that in a loop over 5,000 orders and the arithmetic stops being academic.

The alias trick now works against you

Aliasing several metafieldsSet calls into one request is now a cost multiplier rather than a saving. The base 10 is charged per alias, and owners are not deduplicated across aliases. So the familiar optimisation of bundling writes into a single round trip, which used to flatten 10 points across several logical operations, now charges the base for each one and counts the same order twice if it appears in two aliases.

This is the part that will bite quietly. Alias bundling is exactly the kind of thing that gets written once, works, and never gets revisited. Nobody instruments it. It shows up as a sync job that started throttling in mid-September for no reason anyone logged.

What we would change in a sync job this week

Group writes by owner before you batch them, not by metafield count. The old model made batch size the only lever worth pulling, because 25 metafields on 25 owners cost the same as 25 on one. That is no longer true, so the shape of the batch is now the optimisation. Collapse every metafield destined for the same product or variant into one call. Never let a batch straddle 25 distinct orders if you can help it.

Then audit where you are putting order metafields at all. A weight of 10 against a variant's 2 is Shopify telling you something about intended use. Order metafields written in bulk, after the fact, on a schedule, are usually a workaround for state that belongs in a system of record rather than on the order. We see this constantly in back-office automation work: the order object becomes the dumping ground for fulfilment flags, carrier references and ERP identifiers because it is the object everyone can see. That pattern just got priced.

Third, instrument the cost. The response returns the actual charged cost, and after this change it varies per call in a way it never did before. A sync job that does not log its own throttle status is now flying blind against a formula it cannot predict from payload size alone. This matters more on standard and Advanced plans than on Plus, where the 1,000 per second restore rate absorbs most of it.

For merchants on headless Shopify builds, the practical read is that metafield architecture is now a performance decision as well as a modelling one. Deciding whether a piece of data hangs off the order or off the variant used to be a question of where it reads most naturally. It now has a number attached, and the number is 5x.

Where to dig deeper

Related reading

Want this done right on your store?

We engineer premium e-commerce end-to-end, Magento Hyvä, Shopify Plus, mobile and automation. A two-week store audit turns ideas like the one above into real numbers and a prioritised roadmap for your store.

Get new posts in your inbox

Two a month at most. Hyvä, automation, motion budgets and the boring parts of shipping. No filler, no spam.

We use your address only to send new posts. Unsubscribe any time.