50,000 Products (With Images)
Super Speedy Imports imported 50,000 WooCommerce products with images in under 6½ minutes — versus 65h 59m for WP All Import Pro on the same server. Read this one with care, though: a one-off fresh import of 50,000 products isn’t something most stores do often, and this particular feed reuses images in a way that flatters the disk figures (explained below). The result that matters for most people is the everyday recurring update. Full per-stage timings, dataset and a reproduce bundle are below.
Summary
- Result: ~620–670× faster than WP All Import Pro (385s / 351s vs 237,540s).
- How realistic is it? Honestly, not very — see the caveat below. A first-time bulk import of 50,000 products is uncommon, and the gap on a realistic fresh import will be smaller. The realistic, repeatable win is recurring updates.
- Disk: SSI added 1.6 GB vs WP All Import’s 50.5 GB — but this benchmark’s image reuse exaggerates that gap. The genuine, repeatable savings come from SSI’s image de-duplication and its control over generated image sizes (see below).
- SPRO: shaves ~8% off a fresh bulk load (351–357s vs 380–385s) — modest here; its real value is recurring updates.
- Reproducible: full dataset + configs linked below.
Multiple runs (wall-clock seconds, 8 parallel workers):
| Config | Run 1 | Run 2 | Products created |
|---|---|---|---|
| SSI (no SPRO) | 385s (6m 25s) | 380s (6m 20s) | 50,000 |
| SSI (+ SPRO) | 357s (5m 57s) | 351s (5m 51s) | 50,000 |
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 |
| Speed-up vs WPAI | 1× | ~622× | ~671× |
| Disk added (see caveat) | 50.5 GB | 1.6 GB | 1.6 GB |
Per-stage breakdown (SSI, no SPRO)
| Stage | Duration |
|---|---|
| load-csv | 22.72s |
| import-taxonomies | 0.41s |
| insert-posts | 4.66s |
| insert-postmeta | 2.63s |
| attach-existing-images | 1.45s |
| upsert-relationships | 1.42s |
| upload-remote-images | 327.64s |
| process-variable-products | 1.84s |
| attach-gallery-images | 6.62s |
| fix-attributes | 12.48s |
| process-deletes | 0.25s |
| Total stage time | 384.35s |
Key findings
- ~85% of the time is image handling. The actual product + database work for 50,000 products takes ~55 seconds; downloading and sideloading images accounts for the remaining ~328s. SSI’s database engine is not the bottleneck at this scale — image I/O is.
- WP All Import’s per-product cost balloons with catalogue size (~0.64s/product at 5k → ~4.75s/product at 50k), because it re-queries and re-downloads per product. SSI stays flat via bulk SQL and parallel workers — which is why 50k shows hundreds of × rather than the ~24× seen at 1k.
- The disk gap is mostly a benchmark artifact — but it points at two real SSI features. Because this feed reuses ~5,000 images across 50,000 products, WP All Import re-downloads each one many times, inflating its footprint to 50.5 GB; on a realistic catalogue that gap would be far smaller. What is real and repeatable: SSI (1) de-duplicates by image URL, so each unique image is downloaded and stored once however many products use it, and (2) lets you reduce or skip the extra image sub-sizes WordPress generates for every upload — often the bigger saving on real catalogues.
- SPRO trims the fresh-load image stage modestly (~8%); its decisive advantage is on recurring updates, not first-time bulk loads.
↔ Compare: the same test from WP All Import’s side — WP All Import Pro: 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: Super Speedy Imports 2.55.7 (8 parallel workers, default); WP All Import Pro 5.0.6 + WooCommerce add-on 4.0.6 (defaults).
Test setup
- Source: single CSV, 50,000 rows, with image URLs.
- Workers: 8 (SSI default).
- Runs: 2 per config (no-SPRO, +SPRO indexes+options).
- 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 import scope, same expected end-state (50,000 products created) for both plugins. WP All Import’s run produced the correct catalogue — the difference is time (and disk, with the caveat below).
- Headline figure is total wall-clock duration; records/sec 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, drawn from a pool of ~5,000 images.
Caveat — this fresh-import scenario isn’t very realistic. Two reasons. 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 our 50,000 full update benchmark — that’s the one to judge us on). Second, the 50,000-row feed reuses ~5,000 images cycled roughly 10× across products, so it downloads ~5,000 unique images, not 50,000 — call it “50,000 products, ~5,000 unique images.” A more realistic fresh-import comparison, using unique images at several sizes, is in preparation.
Why SSI uses so much less disk here
The headline 1.6 GB vs 50.5 GB is partly a quirk of the reused-image feed: WP All Import downloads an image afresh for every product that references it, so a heavily-reused pool balloons its storage. Take that with a pinch of salt. But the benchmark does usefully demonstrate two things SSI genuinely does to keep disk under control on any catalogue:
- Image de-duplication. SSI keys images by URL and downloads/stores each unique image once, then re-uses it across every product that references it — no duplicate files.
- Control over generated image sizes. WordPress normally creates several scaled copies (thumbnail, medium, large, …) of every upload, which multiplies disk use. SSI lets you reduce or skip those extra sizes — frequently the larger saving on a real catalogue full of unique images.
Reproduce
Everything needed to repeat this run is in the bundle below: the 50,000-row CSV feed, the taxonomy definitions, the Super Speedy Imports config, the WP All Import template, and our raw timing results.
- Download: ssi-benchmark-50000-with-images.zip (~24 MB)
- Contains:
shirt-test-50k-with-images.csv,taxonomies.json,ssi-import-config.json,wpai-template-export.json,results-ssi.json,results-wpai.json, and aHOW-TO-REPRODUCE.md.
Steps (Super Speedy Imports)
- Clean WooCommerce site with Super Speedy Imports installed.
- Register the taxonomies:
wp ssi import-taxonomies taxonomies.json - Create the import:
wp ssi create benchmark product /path/to/shirt-test-50k-with-images.csv ssi-import-config.json - Run it:
time wp ssi <id> --workers=8
If your results differ significantly, tell us — we’d like to know.
FAQ
Is this realistic?
Be honest with yourself about your workflow: a one-off fresh import of 50,000 products is uncommon, and this feed’s image reuse makes it less representative still. What’s realistic — and what most stores do constantly — is updating an existing catalogue from a supplier feed. That’s the benchmark to judge us on.
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 does SSI use less disk?
Two genuine reasons, independent of this benchmark: SSI de-duplicates images by URL (each unique image stored once), and it lets you cut the number of scaled image sizes WordPress generates. The eye-catching 32× figure here is inflated by the reused-image feed, so don’t read too much into the exact number — but the underlying disk-saving behaviour is real.
Does this work on shared hosting?
This was run on a modest 4-vCPU / 8 GB VPS. On shared hosting both plugins will be slower, but SSI’s bulk-SQL approach is far gentler on constrained resources — and WP All Import’s 66-hour run would almost certainly time out repeatedly on shared hosting.
Why is SPRO separate?
Scalability Pro is a distinct product focused on serving speed and fast recurring updates. On a one-off bulk load its effect is small (~8% here); we show it separately so you can see exactly what it does and does not change.
Can I reproduce this locally?
Yes — download the bundle above. Absolute times depend on your hardware and image-source latency, but the relative speed-up should hold.
