Very slow contact import in Mautic v7.x

Product Support
1

Your software
My Mautic version is: 7.1.1
My PHP version is: 8.3.30
My Database type and version is: mariadb: 10.11.16

Your problem
My problem is:

Hello Mautic community,

I am currently working with a project based on Mautic Open Source 7.x, running in Docker with the following environment:

  • Mautic 7.x
  • MariaDB 10.11
  • Mautic container: mautic/mautic:latest
  • Background imports executed with:
php bin/console mautic:import --no-interaction

For testing, I divided the contacts into three CSV files containing 23,400 rows each and configured:

'parallel_import_limit' => 4,

I then started three import processes simultaneously. All contacts were new and the database was clean.

These were the results:

Import 1:
23,400 contacts created
Time: 795.21 seconds

Import 2:
23,400 contacts created
Time: 793.56 seconds

Import 3:
23,400 contacts created
Time: 790.44 seconds

The actual total elapsed time was approximately 13 minutes and 24 seconds for 70,200 contacts.

Can I improve this time?
Is there another solution that allows for faster importing?

2

About 30 contacts/sec per process is normal for Mautic’s importer. Each row goes through the full contact model: dedupe lookup on unique fields, events/listeners, audit log, company matching, and segment/owner handling. That’s why it scales poorly. Some things that do help:

- **Fewer unique identifier fields.** Every unique field adds a lookup per row. Keep it to `email` only, and make sure that column is indexed (Contact fields → email → “Is unique identifier” and index it).

- **Skip company matching.** If you don’t need companies, don’t map a company column. Company lookup/creation adds noticeable time.

- **Batch size:** `php bin/console mautic:import --limit=…` plus several runs in parallel, which is what you already do. Past 3-4 processes, MariaDB row locks usually cancel out the gains.

- **DB tuning** for bulk inserts: enough `innodb_buffer_pool_size`, and during the import `innodb_flush_log_at_trx_commit=2`. Disk I/O in Docker volumes is often the real bottleneck.

- **No other heavy jobs during the import.** Stop `mautic:segments:update` / `mautic:campaigns:update` crons until it finishes, so they don’t fight over the same tables.

- **APCu/Redis cache** for Symfony and plenty of PHP `memory_limit` for the CLI.

If you need something much faster, e.g. hundreds of thousands of contacts, the common route is the batch API (`POST /api/contacts/batch/new`, up to ~200 per request) in several parallel workers, or for an initial migration a direct SQL insert into `leads` followed by `mautic:segments:update`. The SQL route bypasses Mautic logic, so test it on a copy first.

3

Hi

Import performance can be improved, but parallel processing should be enabled deliberately. It is not simply a safe speed increase: running several imports at the same time changes the order in which contact updates are applied.

For the normal scenario, I recommend:

  1. Use background imports instead of processing large CSV files in the browser.
  2. Run mautic:import through cron or a dedicated worker.
  3. Verify that the email column is indexed in the leads table.
  4. Import only the columns that are actually required.
  5. Split very large files into reasonable parts.
  6. Measure one worker first, then gradually increase the batch size or worker count.

Mautic has a setting that allows multiple imports to run concurrently. However, parallel imports are not equally safe in every scenario.

Main risk

Mautic does not know that one import is logically newer than another. For example:

  • import n contains older data;
  • import n+1 contains newer data;
  • both files contain the same email addresses;
  • both imports run at the same time.

Mautic does not compare the import number, source-file date, or business version of the row. The value written last to the database wins.

This can happen:

  1. Import n+1 starts first and contains the current data.
  2. Import n starts shortly afterwards.
  3. Import n+1 finishes first.
  4. Import n continues processing and writes the older values.
  5. The contact ends up containing outdated data again.

This may not produce an error in the interface. Both imports can finish successfully and their counters can look correct. The problem is the order in which the rows were applied.

What our testing showed

We tested this scenario on a clean Mautic 7.2.1 installation using synthetic databases with 100 and 1,000 contacts. Each scenario was repeated three times.

Results:

  • sequential n, then n+1 always left the n+1 values;
  • sequential n+1, then n always left the older n values;
  • when n+1 started first and both imports overlapped, the older n values remained in all six tests;
  • when the start order was reversed, the newer values remained;
  • with the ordinary queue path, the final state also depended on which worker actually wrote the rows last.

There were no duplicate contacts, deadlocks, or mixed values in the tested text, phone, and numeric fields. However, the absence of an error does not mean that the final data was the newest data.

A separate test also showed that if several workers start at exactly the same time, they can race while selecting queued imports. In that situation, more than one process may attempt to claim the same queued import. This is a separate queue race, but it further demonstrates why uncontrolled parallel execution can be risky.

When parallel imports are safer

Parallel processing is safer when:

  • each file contains completely different contacts;
  • the same email address cannot appear in multiple files at the same time;
  • imports do not update the same contacts;
  • an older export is not being re-imported;
  • the update order does not matter;
  • the database has sufficient CPU, memory, and I/O capacity.

If several files may contain the same email addresses, especially when updating existing contacts, sequential processing is safer.

Practical recommendation

Start with one worker and measure the result:

php bin/console mautic:import --limit=1000

Then gradually increase the batch size or worker count while monitoring:

  • actual throughput;
  • CPU and database load;
  • the number of imports in progress;
  • errors and delayed imports;
  • final values for selected control contacts;
  • duplicate contacts and stale overwrites.

Increasing the number of workers does not always make imports faster. In our testing with 60,000 contacts, a limit of 4 was safer and faster for mixed and update-heavy workloads than 8. A limit of 8 provided an advantage mainly for imports containing mostly new contacts.

In short, parallel imports can be useful for completely new, non-overlapping contacts. They can also cause newer data to be overwritten by older data when several files update the same email addresses.

In other words, in this scenario, sequential importing is not simply a slower option. It preserves the intended business logic for processing the data. Parallel importing without version control may provide higher throughput, but it can also make the final state of contacts nondeterministic.