Shopify Markets vs a Multi-Store Setup: How We Pick for Cross-Border Brands

Every brand that crosses €1M in annual revenue eventually asks the same question: do we run one Shopify store with Markets, or spin up a second (or fifth) store per region? The answer is rarely clean, and the wrong call costs you six months of platform migration work. Here's the framework we use when a client puts the question on the table.

The short version

Shopify Markets — the built-in international layer — handles currency, language, domain routing, duties, and per-market pricing from a single store. A multi-store setup gives you separate Shopify instances per country or region, each with its own catalog, theme, apps, and admin.

Markets is the default we recommend. It's cheaper to run, easier to keep in sync, and Shopify has invested heavily in it since 2022. But there are four hard constraints that push us toward multi-store, and if you hit any two of them, the math flips.

When Markets is the right answer

Markets works well when your catalog is essentially the same across regions, your tax obligations are manageable through Shopify Tax or Avalara, and your marketing team is happy translating content rather than rewriting it.

Concretely, we lean Markets when:

• You sell the same SKUs in every country, with only price and currency changing
• Your brand voice and merchandising translate cleanly (a hoodie is a hoodie)
• You need fast time-to-market — Markets can be live in two or three weeks
• Your finance team is OK with one consolidated payout per currency through Shopify Payments
• You're running Hydrogen or a custom headless front end and want a single GraphQL endpoint

The operational win is real. One product update, one inventory source, one set of apps to pay for. For a brand doing €5M across six European countries, the difference between one store and six is roughly €2,000–€4,000 per month in app subscriptions alone, before you count the engineering overhead of keeping them in sync.

What Markets actually gives you

Under the hood, Markets exposes per-region settings for domains, languages, currencies, pricing rules, payment methods, and shipping. The Storefront API respects the @inContext directive, so a headless front end can query the right variant for the right market without juggling multiple stores:

query ProductByMarket($handle: String!) @inContext(country: DE, language: DE) {
  product(handle: $handle) {
    title
    priceRange {
      minVariantPrice { amount currencyCode }
    }
    metafield(namespace: "specs", key: "care") { value }
  }
}

That single directive change — country: DE to country: FR — is what makes Markets attractive for headless teams. You're not maintaining six API clients.

When multi-store is unavoidable

There are four scenarios where we stop recommending Markets, even reluctantly.

1. Genuinely different catalogs

If your German catalog has 800 SKUs and your US catalog has 1,200 — with different bundles, different naming, different compliance copy — Markets will fight you. You can hide products per market, but you can't easily run two separate merchandising strategies on one product graph. Collections, metafields, and navigation are shared. Your merchandiser ends up writing conditional logic into theme code, which is a smell.

2. Regulated categories

Cosmetics, supplements, electronics with regional certifications, alcohol, anything with ingredient or warning labels that differ by jurisdiction — these are painful on a single store. Each product needs market-specific descriptions, disclaimers, and sometimes entirely different variants for compliance. Metafields can carry the data, but the editorial workflow becomes brittle. A second store with a dedicated catalog is usually cheaper than the QA cost of getting it wrong once.

3. Local payment and tax complexity

Shopify Payments doesn't cover every country, and where it doesn't, you're stitching together gateways like Mercado Pago, PayU, Razorpay, or local bank rails. If you need a Brazilian CNPJ-registered entity collecting in BRL, a Mexican RFC entity collecting in MXN, and a US LLC collecting in USD, you're not running one store — you're running one storefront experience backed by three legal entities. Multi-store maps cleanly to that.

4. Independent growth teams

When each region has its own marketing team with its own roadmap, app stack, and release cadence, forcing them onto one Shopify admin creates constant collisions. We've seen teams ship breaking theme changes to each other on a Friday afternoon. Separate stores give each team autonomy at the cost of duplication.

The hybrid pattern we use most often

For mid-market brands — call it €10M to €80M GMV — neither pure model wins. The pattern we deploy most often looks like this:

• One primary Shopify store with Markets for your home region plus any markets that share legal and operational structure (e.g. EU countries under one entity)
• A separate store per legal entity where tax, payments, or compliance demand it (e.g. US, UK post-Brexit, Brazil)
• A shared headless front end that talks to both stores via the Storefront API, with a thin routing layer deciding which backend serves a given domain

The routing layer is the interesting bit. It's usually 50 lines of edge middleware:

export default {
  async fetch(request: Request): Promise<Response> {
    const url = new URL(request.url);
    const host = url.hostname;

    const backend = pickBackend(host);
    // backend = { shopDomain, storefrontToken, market }

    request.headers.set('x-shop-domain', backend.shopDomain);
    request.headers.set('x-storefront-token', backend.storefrontToken);
    request.headers.set('x-market', backend.market);

    return fetch(request);
  }
};

function pickBackend(host: string) {
  if (host.endsWith('.us')) return US_STORE;
  if (host.endsWith('.br')) return BR_STORE;
  return EU_STORE; // Markets handles DE, FR, IT, ES
}

From the customer's perspective it's one brand. From the finance team's perspective it's three clean ledgers. From the engineering team's perspective it's one front end with environment-aware API clients.

The costs nobody quotes you up front

A few line items we've learned to flag in scoping conversations:

• App licensing. Most Shopify apps charge per store, not per market. Klaviyo, Gorgias, Loop, Rebuy — they all multiply. Budget for it.
• Inventory sync. If you run multi-store with shared warehouses, you need a middleware layer (Stock Sync, Trunk, or a custom service) to keep stock levels honest. Expect oversells in the first month no matter what you do.
• Customer accounts. Customers don't carry across stores. A shopper who creates an account on your US site can't log in on your EU site. Some brands solve this with a shared identity layer (Auth0, custom OIDC); most just live with it.
• SEO. Multi-store with country TLDs is excellent for international SEO if you implement hreflang correctly. Markets with subfolders is also fine. Markets with subdomains is the worst of both worlds — avoid it.
• Reporting. Shopify analytics doesn't roll up across stores. You'll need a warehouse (BigQuery, Snowflake) and a BI tool from day one if you go multi-store.

A quick decision matrix

When we run this exercise with clients, we score each factor 1–5 and add them up. Above 15, go multi-store. Below 10, go Markets. In between, hybrid.

Factor	Markets-friendly (1)	Multi-store-friendly (5)
Catalog overlap	Identical SKUs	<50% overlap
Tax/legal entities	One	Multiple
Payment gateways	Shopify Payments everywhere	Local rails required
Team structure	One central team	Independent regional teams
Compliance copy	Minimal	Per-market disclaimers
Time to launch	Weeks	Months are acceptable

It's not science, but it surfaces the real disagreements between founders, finance, and engineering before they become migration tickets.

Where we'd start

If you're already on Shopify and weighing this for 2026, do three things this week. First, list every country where you have — or want — a separate legal entity, separate payment processor, or genuinely different catalog. That list is your multi-store candidate set. Second, audit your current app stack and price out what it costs per additional store; that number usually surprises people. Third, talk to your tax advisor before your developer. Architecture follows entity structure, not the other way around.

If you want a second pair of eyes on the call, our team has run this migration in both directions — consolidating four stores into one with Markets, and splitting one overloaded store into three. Neither is fun, but both beat staying on the wrong setup. You can see how we approach this work on our e-commerce services page.