Product data rarely lives in Magento. It lives in ERPs, PIMs, supplier spreadsheets - and getting it into the catalog quickly and safely is a recurring engineering problem. Magento offers several import paths with very different speed and safety profiles. Here is how to choose and how to make each fast.
The Built-In CSV Import
System > Import handles products, customers, prices and more from CSV. It validates before writing (good), processes a few hundred rows per minute (slow), and runs through the admin (risky on big files - browser timeouts are real).
Use it for: small catalogs, occasional updates, merchandisers running their own category or attribute tweaks. Avoid it for: nightly full-catalog syncs of 50k+ SKUs.
FireGento FastSimpleImport
The de facto standard for serious imports is the community module FastSimpleImport, which wraps Magento’s native import model in a developer-friendly API:
use FireGento\FastSimpleImport\Model\ImporterFactory;
$importer = $this->importerFactory->create();
$importer->processImport($rows); // array of assoc arrays, one per product
$importer->setValidationStrategy('validation-skip-errors');
$importer->setBehavior(\Magento\ImportExport\Model\Import::BEHAVIOR_APPEND);
It runs the same validated import engine as the admin CSV path but from CLI or cron, at multiples of the speed - and it accepts arrays, so your ERP adapter never touches CSV serialisation. For most mid-market integrations this is the sweet spot: fast enough, battle-tested, and using core validation rules.
The Bulk API Path
Adobe’s asynchronous bulk REST API (POST /V1/products with async bulk prefixes) queues operations through RabbitMQ. It shines for distributed systems that already speak REST, and its message-per-entity shape makes progress observable and retries clean. Throughput is lower per message than a batch import, but parallelism across consumers helps.
Performance Discipline
Whatever the path:
- Indexers to schedule mode before importing; reindex affected indexers after, not during
- Chunk imports into batches of a few thousand rows with progress logging - a 200k-row monolith that fails at row 190k is a bad night
- Avoid per-row entity saves (
$product->save()in a loop) - it fires full reindex and cache invalidation per row and is the classic 100x slowdown. Attribute-level mass updates (updateAttributes) are dramatically faster for price/stock fields - Disable cache invalidation listeners during bulk runs where the module supports it, then invalidate once at the end
A Sensible Architecture
For a typical ERP sync: extract deltas (not full dumps) nightly, map to FastSimpleImport arrays in a CLI command, chunk at 2,000, log per-batch results to a file the merchant can read, reindex the touched indexers, and alert on failures. The whole thing is a few hundred lines and runs in minutes where admin CSV took hours.
Import speed problems are almost always architecture problems: per-row saves, on-save indexing, full-dump habits. Fix those three and even large catalogs import comfortably on ordinary infrastructure.