How Many Bulk Operations Can Run at Once on Plus?
Shopify's native bulk-operation concurrency is scoped per app, so two different apps never collide. Each app can run up to five bulk query operations per shop simultaneously on API 2026-01 and higher (verified Sep 2026). Older pinned versions allow one bulk operation of each type at a time. Build the version tracking yourself, because Shopify Plus does not change this ceiling and no app sells a fix.
Your profile — see how the verdict shifts
- Confidence
- High — Read Shopify's bulk-operations query documentation on 2026-09-05. The scoping sentence is explicit: in API versions 2026-01 and higher, each app can run up to five bulk query operations per shop simultaneously, and in versions prior to 2026-01, each app can run only one bulk operation of each type at a time per shop. Both figures are per app, per shop, which answers the collision question directly: two separate apps do not queue behind each other, and the contention a merchant fears between installed apps does not exist at this layer. Neither figure is plan-tiered, so Plus buys no extra concurrency. On the market side we browsed the bulk-editor, inventory-ERP and inventory-sync categories and none surfaced an integration-orchestration platform aimed at this ceiling. The one iPaaS listing we fetched and verified, Patchworks, carries zero App Store reviews and prices only after a sales conversation. Two other orchestration vendors merchants ask about, Celigo and Workato, publish no Shopify App Store listing at all and are configured inside their own platforms (verified Sep 2026). Nothing is sold against this limit, which is why the honest lane is your own queueing and version governance.
- Reference scenario
- $20M–$500M GMV · Shopify Plus · a PIM sync, an inventory sync and a custom ERP connector · at least one integration pinned to an API version older than 2026-01 · in-house or agency dev bench
- As of
- September 2026
Decision at a Glance
| Your profile | Verdict | Why |
|---|---|---|
| Several third-party apps, each installed separately | WAIT | Each app carries its own allowance, so a dozen installed apps do not contend for one pool. Nothing to build and nothing to buy; the architecture already isolates them (verified Sep 2026). |
| One custom integration on API 2026-01 or higher | WAIT | Five simultaneous bulk query operations per shop is far more headroom than a single nightly sync uses. Revisit when the same app starts firing several jobs from the same schedule. |
| One app or integration firing several jobs at once | BUILD | Collisions happen inside an app, not between apps. A job queue that caps in-flight operations at five and holds the rest is a few days of work and removes the failure entirely. |
| Integrations pinned to an API version older than 2026-01 | BUILD | Those integrations still get one bulk operation of each type at a time per shop, whatever the plan says. Upgrade the pinned version deliberately, then test, because concurrency behavior changes underneath you. |
What Concurrent Bulk Operations Limit Actually Drives
| Outcome | Impact | How it works |
|---|---|---|
| Operational efficiency | High | A failed nightly job blamed on app contention sends a team hunting the wrong cause, and the same investigation repeats every time the schedule overlaps. |
| Data & insight | Medium | A job ledger recording start time, API version and outcome for every bulk operation turns an intermittent failure into a pattern anyone can read. |
| Revenue — indirect | Medium | Inventory and price syncs that silently queue behind each other publish late, so the storefront sells against yesterday's numbers until the backlog clears. |
| Customer experience | Low | Buyers only meet this limit indirectly, through stale stock levels on a store whose sync backed up overnight. |
Spend ceiling: Size the spend to a queue, not a platform. Capping in-flight operations and keeping a version register is $8,000–$25,000 at most and often a few days (Deploi estimate, illustrative); an orchestration platform costs multiples of that and was never sold as a fix for this ceiling.
What buying enables (top apps)
- + One managed layer between your systems and Shopify, which reduces how many independent integrations you maintain
- + Vendor-tracked API versions across every flow the platform runs, removing one register you would otherwise keep
- + Prebuilt connectors for common ERP, PIM and 3PL endpoints, which is genuine time saved on the transport
- + Retry, alerting and flow monitoring out of the box rather than as custom work
What building additionally unlocks
- + A concurrency cap that matches the documented ceiling exactly, at five in-flight operations per app on current API versions
- + A register that tells you what each integration will actually do, rather than what the current documentation says
- + Deliberate version upgrades scheduled outside peak season, with a test run for the behavior change
- + A job ledger that makes intermittent overnight failures explainable instead of anecdotal
Find Your Verdict in 3 Questions
Are the jobs you're worried about running inside separate installed apps?
Yes: Your verdict: WAIT — the allowance is per app, so those apps never contend with each other for a bulk-operation slot.
No: Go to question 2.
Does every integration you own pin API version 2026-01 or higher?
Yes: Go to question 3.
No: Your verdict: BUILD — the older ones still get one bulk operation of each type at a time; register the versions and plan the upgrades.
Does any single integration fire more than five bulk query operations at once?
Yes: Your verdict: BUILD — cap in-flight operations at five and queue the rest, releasing slots on polled status ($8,000–$25,000, Deploi estimate, illustrative).
No: Your verdict: WAIT — five concurrent operations per app is more headroom than your jobs use; revisit when a migration needs parallelism.
The TCC Scorecard — 12 Dimensions
TCC — Total Cost of Capability: what it actually costs to have this capability over three years, whichever way you get it. Each dimension is scored 0–5 for both paths. How we score →
| Dimension | Buy | Build | Why |
|---|---|---|---|
| Cost | |||
| Acquisition & implementation | An integration platform is a procurement cycle and a migration of existing flows; a job queue with a concurrency cap inside your own integration is days of work (Deploi estimate, illustrative). | ||
| Recurring fees | Orchestration platforms license annually and price on connections or volume, with the one verified listing quoting only after a sales conversation; your own queue has no licence line. | ||
| Maintenance & upgrades | A platform vendor tracks Shopify's API versions across every flow it runs; doing it yourself means a register of which integration pins which version, reviewed at least once a year. | ||
| Switching & exit | Flows built inside an orchestration platform stay there when you leave it; a concurrency cap and a job queue are twenty lines in a repository you already own. | ||
| Risk | |||
| Vendor risk | The single verified listing in this lane carries zero App Store reviews, and two orchestration vendors merchants name have no Shopify listing at all (verified Sep 2026). | ||
| Security & compliance surface | Routing every integration through one platform concentrates catalog, customer and order data in a third party; a queue inside your own service adds no new data holder. | ||
| Platform-deprecation exposure | The concurrency rule already changed once at API 2026-01, so any integration that pins a version inherits whichever behavior that version shipped with until someone moves it. | ||
| Value | |||
| Fit to requirement | No product is sold against this ceiling, so a platform helps only as a side effect of centralizing flows; a queue that caps in-flight operations at five addresses it exactly. | ||
| Time to market | A concurrency cap ships this sprint; consolidating existing integrations onto a new platform is a quarter of migration before it fixes anything. | ||
| Performance & scale | Five concurrent bulk query operations per shop is real parallelism for a migration, and only code you control can schedule work to use all five without overrunning them. | ||
| Data ownership & AI-readiness | A job ledger recording which operation ran when, under which API version, is the record that makes a failed nightly run explainable months later. | ||
| Focus & opportunity cost | Version governance is unglamorous and cheap, and it prevents the class of bug where a pinned integration behaves nothing like the documentation the team is reading. | ||
The App Landscape
| App | Status | Pricing | Best for |
|---|---|---|---|
| Shopify GraphQL Bulk Operations API | Native — First-party platform behavior, not a product. A bulk query allows a maximum of five total connections and two levels deep for nested connections, and has to complete within 10 days or it is stopped and marked as failed. Concurrency is version-gated: five simultaneous bulk query operations per shop on API 2026-01 and higher, one bulk operation of each type at a time on earlier versions (verified Sep 2026). None of it is plan-tiered. | Included with every plan; no tier raises these ceilings | Understanding why two apps never queue behind each other, and why one app can queue behind itself |
| Patchworks | Live — IPaaS alternative pitched at multi-system retail stacks, with a strong agency channel | Tiered platform subscription | Consolidating several point integrations into one managed middleware layer |
| Integration orchestration platforms (iPaaS) | Category — The nearest thing to buying an answer here, and it is not one. Orchestration platforms centralize flows, which incidentally reduces the number of independent jobs hitting your store, but none is marketed against the bulk-operation concurrency ceiling. Celigo and Workato, two vendors merchants name in this conversation, publish no Shopify App Store listing and are configured inside their own platforms instead (verified Sep 2026). | Quote-based at the platform tier; confirm on the current listing | Reducing integration sprawl, not raising a documented API ceiling |
| Job queue and API version register (custom) | Build lane — Cap in-flight bulk operations at five inside your own integration, hold the rest in a queue, and keep a register of which API version each integration pins with the concurrency behavior that version implies. Small, boring and the only lane that actually addresses the limit. | $8,000–$25,000 one-time (Deploi estimate, illustrative), then upkeep | Any team running more than one bulk job from the same app or integration |
The Build Path
- Write down which API version each integration pins: Start with a register: integration name, pinned version, concurrency behavior that version gives you, and who owns the upgrade. Teams routinely read the current documentation while running a version that behaves differently, and this one table ends that argument permanently.
- Cap in-flight operations and queue the rest: Hold a counter of running bulk operations inside your integration, cap it at five on API 2026-01 or higher and at one per type below that, and queue anything over the cap. Poll status to release slots rather than assuming a job finished.
- Upgrade the pinned version on purpose, then test: Moving an integration from a pre-2026-01 version to a current one changes concurrency underneath it, which is a behavior change worth a test run before a peak season. Do it on a schedule you choose rather than in the week the old version leaves Shopify's 12-month support window.
- Effort band
- $8,000–$25,000 for a job queue with a concurrency cap, status polling and an API version register — Deploi estimate (illustrative); lands at the low end of the $10–25K contact-form band, and a queue alone is often a few days
- Typical timeline
- 1–3 weeks, with the version register done in the first afternoon (Deploi estimate, illustrative)
- Maintenance, honestly
- ~15% of build cost per year (Deploi estimate): roughly $1,500–$4,000/yr (Deploi estimate, illustrative), most of it the annual version review rather than the queue itself.
- What you own — and what you take on
- You own: the queue, the concurrency cap, the job ledger and the register of pinned versions. You take on: the annual review, and the discipline of upgrading a version deliberately rather than discovering the change during a peak week.
3-Year Total Cost of Capability
| Buy (app path) | Build (custom path) | |
|---|---|---|
| Year 0 (setup) | $20,000–$50,000 (licence plus flow migration) | $8,000–$25,000 |
| Years 1–3 (recurring) | $36,000–$90,000 | $4,500–$12,000 (upkeep) |
| 3-year total | ≈$56,000–$140,000 | ≈$12,500–$37,000 |
- † All figures illustrative samples for the reference scenario — not quotes, not verified pricing.
- † Buy column: an integration orchestration platform at a mid enterprise tier plus implementation services, modeled as an illustrative band because the one verified listing prices only after a sales conversation.
- † Build column: a job queue with a concurrency cap, status polling, a job ledger and a version register; three-year horizon.
What the Sticker Price Hides
On the buy path
- — No platform is marketed against this ceiling, so a purchase justified on collision risk is justified on the wrong thing
- — Quote-based pricing means the number arrives after the architecture is chosen; the one verified listing sets billing after a sales conversation
- — Consolidating flows onto one platform makes that platform a single app, which means its jobs now share one allowance
- — Flows, transforms and retry logic built inside the platform do not leave with you
On the build path
- — Teams design for five concurrent operations while an integration quietly pins a pre-2026-01 version and gets one
- — A queue that releases slots on a timer rather than on polled status will overrun the cap under load
- — Nobody owns the version register unless a name is written next to each integration
- — ~$1,500–$4,000/yr upkeep, mostly the annual version review (Deploi estimate, illustrative)
What Merchants Say
Merchants keep asking whether installing another sync app will make their existing jobs collide, and the answer disappoints in a good way: the allowance is per app, so the new install brings its own.
Engineering teams report the opposite surprise, where two developers read the same documentation page and see different behavior because their services pin different API versions.
If You Change Your Mind Later
If you bought and outgrow it
Leaving an orchestration platform means rebuilding the flows, transforms and retry rules that lived in its builder, because none of that is portable. Your Shopify data is untouched, so this is a logic migration rather than a data migration. Export flow documentation and a sample payload for every integration while the licence is still active, and expect the rebuild to take longer than the original setup did.
If you built and want out
Nothing strands. A concurrency cap, a queue and a version register are code and documentation you already own, and they keep working if you later route some flows through a platform. The register in particular outlives every other artifact here, because the next team inherits a straight answer about which integration runs on which API version.
When This Answer Changes
We're watching for:
- ▸ A future API version changing the five-simultaneous-operation allowance, which would move the cap in every queue built against it
- ▸ The API version any integration pins approaching the end of Shopify's 12-month support window, which forces the concurrency behavior to change
- ▸ Any orchestration vendor publishing a Shopify App Store listing with real review volume, which would finally give this lane public evidence
Verdict change log:
- 2026-01-01API version 2026-01 raised bulk query concurrency from one bulk operation of each type at a time per shop to five simultaneous bulk query operations per shop, per app. The change is version-gated rather than plan-gated, so an integration pinned to an earlier version still gets the old behavior on a Plus store. That split is why two teams on the same store can describe the ceiling differently and both be correct.
Common Questions
Can two Shopify apps run bulk operations at the same time?
Yes. The allowance is scoped per app and per shop, so separate apps never queue behind each other. On API versions 2026-01 and higher, each app can run up to five bulk query operations per shop simultaneously (verified Sep 2026). Installing another sync app brings its own allowance rather than dividing yours.
How many bulk operations can run at once on Shopify Plus?
Five per app, per shop, on API version 2026-01 and higher, and the number comes from the API version rather than the plan (verified Sep 2026). Plus raises rate limits, taking GraphQL Admin API cost to 1,000 points per second against 100 on standard plans, but bulk-operation concurrency reads the same on every plan.
What happens if our integration pins an older Shopify API version?
An integration pinned to a pre-2026-01 API version gets one bulk operation of each type at a time per shop (verified Sep 2026). A Plus store changes nothing about that. Record which version each integration pins, upgrade deliberately with a test run, and expect concurrency behavior to change the moment the pinned version moves past 2026-01.
Your Next Steps
If you're going with BUILD(matches your selected profile)
- Build the register: every integration, its pinned API version, and the concurrency behavior that version gives it
- Name an owner for each row, because an unowned version never gets upgraded
- Cap in-flight bulk operations inside each integration and release slots on polled status, not on a timer
- Log every bulk operation with its start time, API version and outcome so collisions are visible rather than inferred
- Schedule version upgrades outside peak season and test concurrency behavior after each one
If you're going with WAIT
- Confirm each job runs inside a separate app before concluding there is no contention
- Check the pinned API version of anything custom, since the documentation describes the current one
- Watch for the pattern that actually signals trouble: one app scheduling several jobs at the same minute
- Diary a review when a migration or replatform needs several bulk jobs running in parallel
Official Docs & Sources
- Bulk operations with the GraphQL Admin API — shopify.dev
- Admin API rate limits — shopify.dev
- GraphQL Admin API reference — shopify.dev
Official documentation linked for verification — our verdicts and estimates are our own.
Related Decisions
Should You Build or Buy a Historical Order Export Tool?
Shopify emails any order export past 50 orders and estimates 400,000 items at around 4 hours. The mechanics are identical on every plan, Plus included.
Are Bulk Operation Timeouts a Platform Ceiling or Your Bug?
A Shopify bulk query allows five total connections, two levels of nesting and 10 days to finish (verified Sep 2026). Plus raises none of the three.
Will the Storefront API Hold Up on Your Next Flash Sale?
Shopify says real-buyer requests face no fixed per-minute limit on the Storefront API. The ceiling is checkout creation, and it fails with a 200, not a 429.
Flow HTTP Requests or a Real Integration Build on Shopify?
Send HTTP Request is limited to Plus, Advanced and Grow, waits 30 seconds for a response, and can retry for up to 24 hours. Fine for a few calls, not for a sync.
Should You Build or Buy a PIM on Shopify?
PIM on Shopify is a scale decision: metafields cover most catalogs, PIM apps win at multi-channel breadth, custom pipelines at ERP-grade complexity.
Ready to stop guessing which version you're running?
We build the register first, then the queue. Most teams find at least one integration behaving nothing like the documentation they've been reading, and that discovery alone pays for the exercise.
Contact us todayVerdict scored for the reference scenario above. Estimates are not quotes; app pricing carries its verification date and gets re-verified quarterly. Full scoring anchors: see the TCC methodology.
Read how we score these decisions (the TCC Framework). No affiliate links, no paid placement — no app vendor pays to appear here.