50,000 Products (With Images)
WP All Import Pro imported 50,000 WooCommerce products with images in 65 hours 59 minutes on a 4-vCPU server. The same feed, on the same machine, took Super Speedy Imports about 6½ minutes — roughly 620–670× faster. A note up front: a one-off fresh import of 50,000 products is uncommon, and this feed reuses images in a way that distorts the disk figures (explained below), so treat this as an extreme illustration rather than a typical workload — the everyday job is the recurring update. Full numbers, dataset and a reproduce bundle below.
Summary
- WP All Import Pro result: 65h 59m (237,540s) for 50,000 products with images, ~0.21 products/sec.
- Scenario: 50,000 WooCommerce products with images, fresh import into an empty catalogue — an uncommon one-off; updates are the realistic, repeated job.
- Disk: WP All Import added 50.5 GB vs SSI’s 1.6 GB — but this feed’s image reuse exaggerates that; see the disk note below.
- Compared with: Super Speedy Imports — ~351–385s and 1.6 GB on identical hardware and data.
- Version tested: WP All Import Pro 5.0.6 + WooCommerce add-on 4.0.6 (defaults).
- Reproducible: full dataset + the exact WP All Import template linked below.
Results
| Metric | WP All Import Pro | SSI | SSI + SPRO |
|---|---|---|---|
| Total time | 65h 59m (237,540s) | ~382s (6m 22s) | ~354s (5m 54s) |
| Records / sec | ~0.21 | ~131 | ~141 |
| Time per product | ~4.75s | ~0.008s | ~0.007s |
| Disk added | 50.5 GB | 1.6 GB | 1.6 GB |
| Speed vs WP All Import | 1× | ~622× faster | ~671× faster |
Where the time goes
WP All Import’s per-product cost rises with catalogue size — from ~0.23s/product at 1,000 rows to ~4.75s/product at 50,000 — because each row is processed individually and the work per row grows as the database fills. Super Speedy Imports writes products in bulk SQL across parallel workers, so its per-product cost stays flat; that’s what drives the time difference.
On disk, take the headline with a pinch of salt. WP All Import downloads an image afresh for every product that uses it, so this feed’s heavily-reused image pool inflates its footprint to 50.5 GB — on a realistic catalogue of unique images that gap would be much smaller. The disk difference is more an artifact of this benchmark than a typical result. (It does, fairly, illustrate that SSI de-duplicates images by URL and can trim the scaled image sizes WordPress generates — genuine disk savings, just not 32× in normal use.)
Key findings
- This is the widest time gap in our testing — but also the least typical workload, so weigh it accordingly.
- The 50.5 GB vs 1.6 GB disk figure is largely a benchmark artifact (reused images, re-downloaded per product). Don’t read the exact multiple as a real-world expectation.
- WP All Import produced a correct catalogue; the difference is time (and, with this feed’s caveats, disk).
↔ Compare: the same test from Super Speedy Imports’ side — Super Speedy Imports: 50,000 products (with images) — or read the full Super Speedy Imports vs WP All Import Pro comparison.
Methodology
Environment
- Server: Hetzner CPX32 — 4 vCPU (AMD), 8 GB RAM, 160 GB SSD, Ubuntu 24.04 LTS.
- Stack: WooCommerce 10.3, PHP 8.2, MariaDB 10.6, WordPress 7.0.
- Plugins: WP All Import Pro 5.0.6 + WooCommerce add-on 4.0.6 (defaults, single process); Super Speedy Imports 2.55.7 (8 workers) for comparison.
Test setup
- Source: single CSV, 50,000 rows, with image URLs.
- WP All Import: default settings, run via
wp all-import run <id>. - State: fresh import into an empty WooCommerce catalogue; snapshot-reset between runs.
- Images: enabled — featured image per product (see dataset caveat below).
Rules & measurement
- Same CSV, same hardware, same scope, same expected end-state (50,000 products) for both plugins.
- Headline figure is total wall-clock duration; records/sec, time-per-product and disk delta are derived/measured alongside.
This is not intended as a universal benchmark — your data shape, image sources, hardware and hosting will differ. It is one carefully controlled, fully reproducible scenario.
Dataset
- Products: 50,000 (mix of simple and variable).
- Taxonomies: product_cat, product_brand, plus variation attributes pa_color and pa_size.
- Metadata: SKU, regular/sale price, weight.
- Images: featured image per product.
Caveat — how realistic is this? Not very. First, most stores rarely run a one-off import of 50,000 brand-new products; the common, repeated job is updating an existing catalogue (see the 50,000 full update). Second, the 50,000-row feed reuses ~5,000 images cycled roughly 10× across products — so it’s “50,000 products, ~5,000 unique images,” not 50,000 unique images. Both plugins faced the identical feed, so the head-to-head is fair, but the absolute numbers (especially disk) shouldn’t be read as typical. A more realistic fresh-import comparison, using unique images at several sizes, is in preparation.
Reproduce
Everything needed to repeat this run is in the bundle below, including the exact WP All Import Pro template we used.
- Download: wpai-benchmark-50000-with-images.zip (~24 MB)
- Contains:
shirt-test-50k-with-images.csv,wpai-template-export.json,taxonomies.json, the SSI config (for comparison), results JSON, and aHOW-TO-REPRODUCE.md.
Steps (WP All Import Pro)
- wp-admin → All Import → New Import, upload
shirt-test-50k-with-images.csv. - Map columns to WooCommerce fields — or import
wpai-template-export.jsonif your version supports it (it’s the exact template we used). - Run for a clean timing:
time wp all-import run <id>. (Expect this to take many hours.)
If your results differ significantly, tell us — we’d like to know.
FAQ
Does WP All Import really take 66 hours?
That’s what we measured on a 4-vCPU VPS for a 50,000-product import with images, default settings. The per-row model plus per-product image downloads is what drives it. On shared hosting it would likely time out and need repeated restarts.
Were images really included?
Yes — every product got a featured image. Note the image pool is ~5,000 unique images reused across the 50,000 products (see the dataset caveat). Both plugins faced the identical feed.
Why the huge disk difference — and is it real?
It’s mostly this benchmark. WP All Import downloads an image per product, so this feed’s reused images get stored many times over, ballooning to 50.5 GB. On a realistic catalogue of unique images the gap would be far smaller. The 32× figure isn’t a number to expect day-to-day. The real, repeatable behaviour it hints at: SSI de-duplicates images by URL (each unique image stored once) and lets you reduce the scaled image sizes WordPress generates.
Can I reproduce this locally?
Yes — download the bundle above. Absolute times depend on your hardware and image-source latency, but the relative difference should hold.
