When using API version 2026-04 or later, metafield writes will be limited to 16KB. Apps using API version 2026-01 or earlier are not subject to this new limit. Large metafield values continue to be readable by all API versions, including future versions.
The changelog entry links to the Metafield limits doc. However, the doc does not mention a 16KB limit.
Does the 16KB limit mean that json metafields no longer support 2M characters?
This change is disappointing, to say the least. Given how core of a role metafields and metaobjects (seemed to) play in customizing stores, Iâd even call it irritating. The reason given â âmaintain platform performance and stabilityâ â begs the question why this is happening now, even though the existing, higher limits have been in place for quite a while.
Many of our apps have been using larger metafields for years without any issues. Storing structured data directly in metafields helps us avoid frequent server requests and keeps the app performance fast and efficient.
Reducing the limit to 16KB will require us to change our existing architecture and depend more on external servers, which increases complexity and costs. I kindly request you to reconsider this change for apps that rely on larger metafield data.
This change has a very negative impact. It will negatively affect performance. On the other hand, it is not clear whether, if you stay on versions prior to 2026-04, you will still be able to use the previous limits.
Hey yaâll, I understand the frustration here.
Are there places where 16,000 kilobytes/~16,000 characters are going to be a no-go for you? Can you help me understand the use cases? Are any of the alternatives possible to use, such as metaobject references, lists, or otherwise?
What weâre seeing is extremely large JSON files with largely repetitive data that is pulled into storefronts and parsed on the front end. Where these could be, for example, a metaobject reference that would be smaller in size, and improve storefront performance.
The overall number of values over 16KB is extremely small. However, I donât want to miss the opportunity to understand if those few values have much higher impact.
Yes, this is for JSON as well. All types. Docs will be updated today.
This change will make things really hard for Shopify devs. We are using metafields to store many configurations as JSON and access them from the app theme extension to render things quickly on the storefront. But now we need to figure out ways to store data with logical grouping. I donât understand the point if we will now access more fields and get the same amount of data. Is this really beneficial for the performance?
We had a meeting, and after that, I also explored whether it is possible to store things as metaobject references, but this is also a very limiting factor. With 2048 variants, I need to store at least 2048 references, which makes things really hard.
We want to rely on Shopify infrastructure and store all the data there instead of making calls to our own servers, but with this change, Shopify makes it harder to rely on the Shopify infrastructure.
I am always a big advocate of Shopify, and I think Shopify should make it easier for partners to rely on their infrastructure and handle heavy lifting instead of putting heavy lifting on partners.
I would kindly ask you to reconsider this decision.
I see this going one of two ways:
Apps split up their data across more entities => whatâs the gain here?
Apps move data to their own server => performance hit on storefront (for apps that render on the storefront)
So maybe this change wonât actually have that much of a positive impact?
Also:
The overall number of values over 16KB is extremely small.
So why make such a sweeping change then? If huge JSON metafields are a problem, why not reduce that size from 2M to something more reasonable? Why reduce all the other fields from 64 to 16 KB too?
It doesnât make sense that for years Shopify has promoted using Metafields as storage to build apps essentially as a database, and now itâs being restricted in this way because it completely breaks the functionality.
I tend to use JSON fields a lot ON my metaobjects, and sometimes metafields. I may have vey complex nested systems and frankly, I do not want to have use Liquid to deal with covering defaults and extra evaluation checks.
I prefer to listen for metaobject updates and have a backend job compile all of the data and cover default values and store that as a JSON field. That lets me just use the JSON field in my theme code right away. Awesome. Less lines of code in the theme.
So how do I accurately determine the size of my JSON?
For what I think is a simple structured JSON metafield, I this complete swatch data JSON I store on a shop level metafield is ~58,000 characters and just saving it as a JSON file tells me it is 61kb. This is compiled through custom Color Swatch metaobjects since the natural one doesnât cover multiple color values to represent multi-color without needing an image. Now for this JSON I do Liquid loop the array based JSON (which seems to let me exceed the loop limit without the need to paginate hack and I have 496 swatches to go through) and create the CSS variables via Liquid.
So if what I think is a simple metaobject level JSON field, somehow isnât viable anymore?
In the more complex ones, some nested data is based upon a potential deeply nested JSON structure. I could split it up for each instance to hold its own instead of a complete composite, but now I am completely weary.
More complex? JSON fields! I store compiled membership data on the customer level AND product level for easy data comparison without all of the liquid to once again, access nested metaobject data and cover all sorts of fallback scenarios. I actually find this to be simple. Yeah itâs made from existing metafields and metaobjects but I want âall in oneâ access.
Can we get more metafield size.. 16KB will not help 
It getting tough nowâŚ
When does this change actually take effect? Iâm testing right now and I can still set a JSON metafield value larger than 16KB. Is the 16KB limit already enforced anywhere, or is Shopify reconsidering / delaying this change?
If this is enforced, I expect a large number of apps will have to spend significant engineering effort migrating existing storage approaches. That migration is risky and could introduce bugs, and the immediate impact would be felt by merchants and shoppers.
As it says in the changelog, this will get rolled out with API version 2026-04. So if you use that version, the size limits are enforced. You can still use older API versions for a while, but eventually youâll be force-upgraded.
No, itâs not applied yet @ThomasBorowski , I just tested with 2026-04 and still can set larger 16KB values.
What will be the size limit for a JSON field on a metaobject?
I wonder if a solution for this could be preventing rendering large metafields in liquid? And still allow to fetch them through storefront API. Similar to how itâs handled for discount functions. It only returns metafields if they are smaller than 10KB.
Why not just provide better tooling in liquid to work with large JSON stores?
Why does it matter if data is stored in JSON or metaobjects? Why not just improve the JSON parsing in liquid so you donât have to dump the data onto the storefront? I think if we had first class JSON parsing this problem goes away for everyone.
If changes like this continue to happen I will simply completely stop relying on Shopify infrastructure as a whole. Weâve been forced into the infrastructure, and now it is being pulled out from under us like this.
Time to spend entirely too many hours migrating 1 million+ metafields for my merchants across 4 apps. Time so much better spent actually providing value for merchants.
Anything less than 2MB for a JSON field makes it a non-starter for app database storageâat least for me. Even if I only use 2KB today, I need to sleep knowing my app can scale tomorrow without hitting a ceiling.
Moving forward, a 16KB cap is a hard âno.â Itâs 2026; the last thing I want to regret is choosing a database limited to 16KB when I could have used Postgres with GB-level freedom.
In real-world apps, 16KB is nothing. An offers app with nested rules for power users, a visual builder generating HTML/CSS, or even just a long list of Product/Variant IDs will smash through that limit instantly.
But the real damage isnât the technical constraintâitâs the loss of trust.
Quick solution for now to this size problem would be
For theme side use:
go with something like Cloudflare R2 or JSONBin to store your JSON data and access it via JS on the theme side.
This way, the flow becomes: [Theme extension â JSON API â Res]
instead of:
[Theme ext â Proxy â Your app backend server â DB â Res]
For app only use: Just use the db
Over time, migrate away from Metaobjects and avoid potential issues in the future 