Data migration 0078_populate_carrier_snapshots is not production-safe (per-row save loop over 5 tables)

[mgradalska]

What's happening

The data migration manager.0078_populate_carrier_snapshots is not safe to run against a production-scale database.

Each of its five table loops runs Model.objects.all() followed by a per-row .save(), with no batching, no bulk_update, no chunked iterator, and no progress logging. On databases of any realistic size the migration loads entire result sets into memory and then issues one SQL UPDATE per row across millions of rows. Operators running real workloads cannot apply this migration cleanly without invasive workarounds.

The migration code

modules/manager/karrio/server/manager/migrations/0078_populate_carrier_snapshots.py#L48-L76.

The Pickup block (shortest of the five, representative of all of them):

for pickup in Pickup.objects.select_related("pickup_carrier").all():
    if pickup.pickup_carrier and not pickup.carrier:
        pickup.carrier = create_carrier_snapshot(pickup.pickup_carrier)
        pickup.save(update_fields=["carrier"])

The same shape repeats for Tracking, DocumentUploadRecord, Manifest, and Shipment - five sequential O(N) loops, no shared checkpoint.

Why this is a problem

• .all() materializes the entire result set in memory before iteration begins. On large tables this is unbounded memory growth.
• One SQL UPDATE per row. Each statement carries its own commit overhead, so wall time is dominated by transaction bookkeeping rather than the actual updates. On a live database it also competes with concurrent traffic for the same locks.
• No batching, no chunking, no .iterator(). The standard Django data-migration tooling is bypassed entirely.
• No progress signal. The migration runs for an indeterminate time with no log output, making it indistinguishable from a stuck process from an operator's perspective.
• Five sequential loops in a single transaction. A failure partway through rolls back the entire migration - operators cannot make incremental progress across the five tables.

Suggested direction

Django provides the standard tooling for migrations of this shape: .iterator(chunk_size=N) to avoid loading the whole table, and bulk_update(rows, ["carrier"], batch_size=N) to collapse N round-trips into a small number of CASE-mapped UPDATEs. For migrations that touch tables likely to be large in production, those are worth applying here.

Beyond this migration

The bigger concern is the pattern, not this one migration. Per-row .save() inside RunPython is the recognizable shape - if future migrations land with the same structure, they'll fail the same way. Worth treating as a class of issue rather than a one-off.

Even when a heavy data migration is written well, operators benefit from knowing it's coming. A changelog note flagging migrations that touch large tables (with a rough sense of expected runtime or resource needs) would let operators plan downtime windows, scale resources up beforehand, and avoid being surprised mid-upgrade.