Photo: free stock photography (Unsplash licence) — see imprint
Stop making one request per row
Every HTTP request carries auth, routing and transaction overhead. At 100,000 products that overhead is the entire runtime. The sync endpoint accepts many operations in one payload — that is the whole trick.
Find your batch size empirically
Batches of 50–200 usually win. Too small and you are back to overhead; too large and you hit memory limits and lock contention, and one bad row rolls back the whole batch. Measure on staging with production-shaped data.
Upsert, and be idempotent
Send a deterministic ID derived from your source system, so re-running the import updates rather than duplicates. An import you cannot safely re-run is an import you will be afraid to fix.
Indexers are the hidden cost
After the write, Shopware reindexes. On a big import, let the indexers run once at the end rather than after every batch, and schedule the whole thing for a quiet hour. Otherwise your import is also an outage.
- Sync API + batches of 50–200, measured on staging.
- Deterministic IDs make the import re-runnable.
- Defer reindexing to the end of the import.
Frequently asked questions
Not with one request per product — that is mostly auth and transaction overhead, repeated a hundred thousand times. Send many operations in a single payload via the sync endpoint, run the job in a quiet hour, and let the reindexing happen once at the end. The writing is rarely what hurts. The reindexing after every batch is.
Somewhere between 50 and 200 rows usually wins, but measure it yourself on staging with production-shaped data. Too small and you are back to paying per-request overhead. Too large and you hit memory limits and lock contention — and a single bad row rolls back the whole batch with it. There is no universal number. There is a number for your catalogue.
Because Shopware reindexes after the write, and on a big import that reindexing costs more than the import. If the indexers fire after every batch, your import is also an outage. Let them run once, at the end, and schedule the whole thing for a quiet hour. Most tickets that start with 'the import kills the server' are really indexer tickets.
Probably not today. If the import finishes overnight and nobody notices, leave it alone. What you should fix now is repeatability: derive a deterministic ID from your source system so a second run updates instead of duplicating. An import you are afraid to re-run is the real problem — its runtime is not.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer