Metafield values limited to 16KB

[Darius-Shopify]

Hey folks!

Thanks for all the feedback and dialogue here. In hindsight, we should have shared our intent and reasoning earlier, before the changelog post. We’ll take this back to the team to ensure the community has more opportunities for input before we announce consequential changes like this.

As for the change itself: as James mentioned above, we’ve been facing significant challenges with large metafields impacting storefront performance, and we need a solution that mitigates these issues.

Limiting metafields to 16KB is the simplest safeguard. We considered alternatives, but they would make the metafields/metaobjects model more complex and harder to reason about.

Next steps: We want to better understand your use cases and discuss options. We’re open to revisiting this decision and finding an approach that strikes the right balance for the community and Shopify. We’ll be emailing all impacted apps to schedule time with us, but you can also book directly here: https://calendar.app.google/BksRAb5nUcgSoGyN8

To be clear, we want you to rely on metafields and metaobjects for data storage. That has been driving a lot of our recent investments, like providing a larger and more predictable number of entries for app developers. It would be counterproductive if this decision made you reconsider, so we’re incentivized to find a path forward that works for everyone.

[DanGamble]

Just to start the conversation. Why are people using a meta field as a database vs using metaobject definitions as a table definition and metaobjects as rows?

[patrick]

Because I built my apps before metaobjects and migration is a pain / not simple.

[webx47]

Metaobjects are just a group of metafields, so the 16 KB limit applies there as well. People use them instead of their database or S3 storage because of performance, Liquid access, fewer request calls, and reliability under heavy load. I don’t want Cloudflare to go down along with my R2 bucket on an important sales day while Shopify is still up, and then have someone who used my app upset because it failed them on such an important day.

[Darius-Shopify]

Metaobjects are just a group of metafields, so the 16 KB limit applies there as well.

@webx47 This might already be clear, but wanted to clarify if it isn’t: the 16KB limit would only apply to individual metafields or individual fields on a metaobject. You would still be able to have multiple fields—or fields in a metaobject—that collectively exceed 16KB.

[Kevin_Sieger]

especially for JSON metafields, there are scenarios where migrating to metaobjects just doesn’t make sense. we’re saving product configuration configs (think of it as custom options on steroids) within metafields. each of those is inherently different in structure, making mapping them to a metaobject definition nonsensical.

I get where you are coming from - but this feels like you’re throwing functionality that existed for years under the bus, without a clear indication of what this actually is trying to improve, beyond broad statements

[webx47]

@Darius-Shopify I meant on an individual level.

I also agree with @Kevin_Sieger points; let’s say instead of a single big JSON, I create a metaobject to use as a reference. It’s going to be a pain in the future when I need to change the shape of my data because, right now, to migrate I just need to modify and update individual JSON field. but on this “reference route,” it’s going to be such a big pain when dealing with migrations.

[Marius_Hogas]

@Darius-Shopify

As for the change itself: as James mentioned above, we’ve been facing significant challenges with large metafields impacting storefront performance, and we need a solution that mitigates these issues.

Even using MetaObjects, wouldn’t the same amount of data be dumped in the storefront?

I believe that for this exact purpose it would be better to have more liquid tooling for handling objects.

[Dmitri_Pavlutin]

Metafield values being limited to 16KB is way too low especially for a JSON field. Please reconsider the decision.

Reducing out of the blue from 2MB to 16KB (125 times less!) is another very strange decision, which definitely puts partners in a difficult situation.

[Darius-Shopify]

Thanks for all the feedback folks. There has been some good feedback re simplicity / flexibility of working with JSON that we’re taking into consideration.

We’re discussing options. Will share more details early next week

[Galmis]

Hi,

I have an app that enables merchants to track unique details about individual items, such as serial numbers, warranty durations, and any other business-specific custom information: IMEI, lot numbers, supplier SKUs, you name it. Some merchants track multiple serial numbers per item, i.e. one serial per part.

All items (sold or on hand) are stored in the app’s database, which is the source of truth. It enables merchants to filter items by their unique references in the app.

However, this data can’t be accessed in other parts of Shopify, e.g. notifications, Order Printer app, etc. Merchants want to share these details with their customers for support and warranty purposes. So, the app stores an array of sold items in Shopify order metafield. Additionally, parts of the app access this data through metafields to improve performance. I love how quick the Shopify admin API is, and I’ve been thinking about using metafields for this purpose even more.

I’ll admit that four years ago, when I released the app, I wasn’t sure how the app would evolve, if at all. So, I kept the metafield schema simple, but verbose - a 2M character limit felt safe. Items are stored as an array of objects with the following properties:

• Item ID (as stored in the app’s database)
• Serial number (built-in field)
• Warranty duration
• Merchant-defined custom fields: an array of key-value pairs
• Shopify’s numeric line item ID (no metafield for LineItem)
• Shopify’s numeric product variant ID

For brevity, let’s assume an item currently takes 160 bytes to store (not unreasonable, and may be larger). That’s 100 individual (not line!) items per order, which is probably enough for most merchants most of the time, but laughable for larger B2B businesses, who are showing more interest in the app as I keep improving it and adding new features.

Sure, I could normalise the data and split it across multiple metafields, maybe use metaobjects for some custom fields, but even then, it may not be enough given the 16KB limit.

Let’s assume an average serial number is 16 characters long. That’s ~1000 serial numbers per order. I started thinking about changing the schema last year, when one client hit the 2M-character limit with 50,000 items, or a similar number, multiple times. The client uninstalled the app, but there are still a few orders with over 1,000 individual items. I’m not only worried about the code changes, additional complexity, and data migration, but also about all the clients impacted by the app’s schema changes. Surely, the competitor apps will be affected by this, as well.

For a solo developer like me, it’s becoming really difficult to keep up with the breaking changes these days. First, forced migration to the web components lib + Preact for extensions. Now this…

Please, Shopify, reconsider this!

Thank you

[HSL]

Hi Darius,

I completely understand the negative impact that metafields can have on store fronts. There are also metafields that are not impacting the storefronts, it would be pretty useful to not limit those, for example the order level metafields.

[Philo]

Going from 2MB to 16KB is an insane difference. I use the metafield to save app preferences and inject these into the storefront. For some users it’s 70kb. I understand 2MB is a lot but going all the way down to 16KB is going to be a huge problem. Any reason why it has to be 16KB and not say 250kb? At least for the JSON fields.

[Jurgen_Feuchter]

I also agree that bringing down the size of Metafields from 2mb to 16kb is really big difference. I am wondering though is this change only affecting when we use the api version 2026-04 and above? Or is there a hard date when this change will take effect in all versions?

Also this has not been announces (or not in the changelog or that I have seen yet). But I saw UI extensions files size are also being reduced from 2mb to 64kb. This is also another enormous change which should be discussed as well. If its an issue for metafields, its an even bigger issue for UI Extensions. That size is way too small.

[Alex_Hooper]

This is really frustrating - Shopify has spent years telling partners to use metafields for app data storage. The docs specifically point to app-owned metafields for internal logic, configuration, and workflows. There are even guides translating SQL concepts to Shopify architecture to push us toward native storage, and multiple docs showing JSON config stored in app-scoped metafields for Functions : Data modeling with metafields and metaobjects

If the concern is storefront performance, a more targeted approach would be far easier for app devs to handle, i.e a higher cap for JSON (for example 128KB or 256KB) or resource-specific limits (for example stricter on storefront-heavy resources, looser on order/app config use cases).

P.S. - The UI extension limit from 2mb to 64kb is also going to cause a lot of issues for many of us.

[azy]

Hello

I wanted to attend the meeting, but since I’m a Japanese app developer, I can’t make it, so I’m posting here instead.

I’m currently developing two apps that rely on metafields.

1. Delivery Date/Time Specification App
2. Order Restriction App

“1. Delivery Date/Time Specification App” stores all of its configuration data on its own server, but the storefront stores and references JSON data in metafields.
“2. Order Restriction App” stores all of its app data in metafields, and only references necessary metafields from the storefront (and cart and checkout validation). Therefore, this change will have the greatest impact on this app, as it will require a rethinking of stored data.

• JSON data is referenced directly from JavaScript, so loops within liquid do not occur.
• Metafields referenced by the storefront are kept under 60kB.

Concerns)

1. Both apps contain data that resembles a collection of detailed settings, making it difficult to properly divide it into meta objects. (Date format, shipping options, input text, etc.)
2. Since the app itself doesn’t need it, I don’t store user persistent tokens in the app for security reasons. This means I can’t migrate all users from the app, and the code for the new configuration and the old settings must coexist, bloating the JavaScript on the app’s home screen and storefront.
3. I want to avoid any risk of bugs or other issues caused by the migration. My app is currently working fine, so I would like to keep it as it is if possible.

Thank you to the Shopify team for always doing your best. Metafields are a powerful tool for app developers, and 16kB is too small from the perspective of my app, so I hope the limit will be raised through community discussion.

[Nicholas_Eli]

Can we get an estimated decision timeline on this? Many of us will have to write migrations for this. And the more time to decide how to do that, including testing would be preferable.

[parker]

New limit is only applied on 2026-04 and higher, so I think we have at least 1 year to continue using 2026-01 and migrate.

[Darius-Shopify]

Hey everyone,

Thank you for all the thoughtful discussion in this thread. We have heard your feedback and use cases and that helped shape our thinking on appropriate limits.

Updated limits

When using API version 2026-04 or later, the following limits apply:

• JSON type metafields will be limited to 128KB
• All other metafield types will remain at their current limits (64KB)

All existing apps that use JSON fields (prior to April 1st, 2026) will be grandfathered at the current 2MB JSON limit. We’ve updated the developer changelog post to reflect this and provide guidance on next steps where required.

Why we’re making this change

As shared previously, over the last few months we’ve seen large metafield values impacting storefront performance. In these instances, multiple JSON metafields near 2MB each (equating to tens of MB total), were being rendered on the page slowing down overall page load times. On inspection, a lot of the data in those metafields (or entire metafields themselves) weren’t actually being used by the apps downstream. If these apps had only loaded data they needed, these incidents would’ve been avoided.

That has been the impetus behind this change: to encourage app developers to only load the data they need for the job at hand, to ensure users get a snappy and responsive storefront experience. Smaller fields also give us more flexibility in how we store metafields for optimized loading downstream.

However, through conversations with the community here, it’s clear that we cut the limits too deep. A 16KB limit makes it complex to manage data across multiple metafields / metaobjects. We’ve learned that 128KB is a more reasonable limit — it accommodates the vast majority of use cases while significantly reducing the total data loaded when multiple metafields are pulled into a page.

Why we’re grandfathering existing apps

While it’s possible to redesign around 128KB metafields, our conversations with developers have shown that migration is more complex than we originally anticipated. Therefore, we’re grandfathering all existing apps who use JSON metafields prior to April 1st, 2026 at the current 2MB JSON limit. And, if you’re not grandfathered, we’ve created an intake form if you believe you can’t build your use case within 128KB.

A note on large grandfathered metafields

We still encourage you to use smaller metafields. By loading only the data you need on critical surfaces, you’ll avoid rendering many megabytes of JSON and hurting storefront performance. There are also apps who are nearing our tripwires for incidents. If that’s you, don’t worry - we’ll be reaching to you directly to discuss how we can work together to model your data to ensure you have a lot more room under the threshold. We’ll also be looking into how we can proactively give developers better visibility into the storefront performance impact of their apps directly in the Developer Dashboard.

Thanks for your feedback

Thanks to everyone who reached out with feedback and thoughts. We appreciate the passion you have for the Shopify platform, and the time you took to help us find the right balance here.

[parker]

hi @Darius-Shopify , it’s still confuse to me, existing apps and all published apps prior to April 1st, still can use JSON with 2m limit? Even when using 2026-04 or later?