Shopify Functions: 10KB Metafield Limit is Too Restrictive

Functions
1

I’m currently working with Shopify Functions and have encountered a significant limitation with the 10KB metafield size limit. This restriction is proving to be a bottleneck for many common use cases.

Current Challenge

The 10KB metafield limit in Shopify Functions is easily reached in numerous scenarios:

  • When storing variant IDs for product bundles or product-level discounts (a few hundred variant IDs can quickly consume the available space)
  • When storing detailed business rules and conditions
  • While implementing complex discount logic
  • When managing multiple pricing tiers or customer segments
  • For international stores managing multiple currency rules
  • When handling various promotional scenarios and combinations

Questions for the Community

  1. Is there any roadmap or plans to increase this 10KB limit for Shopify Functions?
  2. How are other developers working around this limitation while maintaining complex business requirements?

We would love to learn from the community’s experience with this limitation and hear any insights the Shopify team might be able to share about potential future improvements

1 Like
2

I haven’t run into this limit myself, but I can definitely see how you could hit it with a large list of products.

Is compression an option?

3

Tried with JWT or Base64. But even that string is huge.

Also, decompressing it for normal use inside the function would consume too many instructions.

4

Ah gotcha. Didn’t consider the instructions limit.

Sorry, wish I had more to add here, I only store small strings of data. But I can see how this limit could be reached with complex use cases.

5

so the way that I’ve dealt with this issue is by storing metafield configuration horizontally.

what I mean by that is, instead of storing all 300 variant IDs in the function configuration metafield, store the configuration for each variant on a variant-level json metafield.

by storing the discount configuration on the variant level, you avoid parsing big blobs of irrelevant data. you also ensure that the size of your input increases with the size of the cart. thanks to a recent update from shopify the input size limit increases when there are more line items in the cart.

"but I will have to keep track of which variants have which discounts in my own database to do that" - yes.

if you want to be extra safe you can store the config as a tuple instead of json. so you don’t have to count the property labels toward your variant limit.

for a custom bundle app last year I also got rid of the gid://ProductVariant to reduce kb - but I would only recommend that if you’re using Rust. with JS there is still an instruction limit gap.

2 Likes
6

That’s amazing! We do exactly the same thing. Using Variant Level Metafields and omit the gid prefix from them.

But sometimes the variants that can be within a bundle are more than 300.

7

ahh gotcha, so are you storing the entire bundle config in each variants metafields’; including all included variants? I can see that hitting the size limit pretty fast

the only data I’m storing on variant metadata is an array of tuples. inside the tuple is a unique bundle id and variant-specific values

then I just have a small json in the discount or cart transform metafield for global discount config.

since everything else is horizontal across variant metadata, this works for any number of variants

8

Is there any new on this?

it is really funny this 10kb limit cause it is causing my data to be large as O(n) size instead of O(1), while n is the number of products in cart.
I think Shopify staff should consider enlarging this limit so we don’t do workarounds that cause the opposite from what was intended at first (saving space).

9

Hi @oribenez! Can you explain why that’s the case?

10

Cart Transform Function Data Storage Challenge: Seeking Better Solutions

Context

I’m developing a bundle creation app that uses Shopify Functions (specifically Product Discount and Cart Transform functions). I’ve encountered a significant limitation with storing bundle data for the Cart Transform function.

The Challenge

When using Cart Transform functions, I need to store bundle data (product IDs, selected variant IDs, discounts, etc.) to process the cart correctly. However, I’ve run into two major issues:

  1. Cart Transform Metafield Limitation:

    • When storing data directly in cart transform metafields, I can only save 4-6 bundles maximum (even fewer if the bundles are large)
    • Exceeding this limit results in the metafield returning “null”
    • This forces me to artificially limit the number of bundles customers can create

  2. Current Workaround Has Drawbacks:

    • I’m currently storing offer data in individual product metafields
    • Each product contains metadata about all bundles it’s part of
    • This leads to significant data duplication

Example of Current Solution

Let’s say we have:

  • 2 bundle offers: Offer_1, Offer_2
  • 10 products: A_1 through A_10

Each product’s metafield contains all relevant offers:

A_1: [{offer_1}, {offer_2}]
A_2: [{offer_1}, {offer_2}]
A_3: [{offer_1}, {offer_2}]
...
A_10: [{offer_1}, {offer_2}]

Problems with Current Solution:

  1. Data Duplication: Instead of storing 2 offers once, we’re storing them 10 times (once per product)
  2. Maintenance Overhead: When updating an offer, we must update metafields on all associated products
  3. Increased Function Input Size: The Cart Transform function receives much more data than necessary (in this example, 20 offer entries instead of just 2)