Potential performance improvements in record merge function (migrateRelatedRecords)

[FelixMalfait]

Summary

AI analysis suggests there may be significant performance issues in the CommonMergeManyQueryRunnerService, specifically in the migrateRelatedRecords method. Note: This is an AI-generated analysis and may not be fully accurate - human verification is needed.

Potential Issues Identified

1. Possible N+1 Query Pattern (needs verification)

In migrateRelatedRecords (lines 388-416), there appears to be a pattern where for each relation field:

• A SELECT query checks if records exist
• Then an UPDATE query migrates them

The SELECT may be unnecessary since UPDATE would simply affect 0 rows if nothing matches.

2. Sequential vs Parallel Execution (needs verification)

The relation migrations appear to run sequentially in a for...of loop rather than in parallel with Promise.all(). For objects with many relations (e.g., Company), this could cause many sequential database round-trips.

3. Repeated Computation (needs verification)

buildFieldMapsFromFlatObjectMetadata() appears to be called inside loops in performDeepMerge and shouldExcludeFieldFromMerge, potentially recomputing the same data multiple times.

Suggested Investigation

1. Profile the merge operation with objects that have many relations
2. Verify if the SELECT before UPDATE is actually necessary
3. Check if parallelizing the relation updates is safe given transaction/constraint requirements
4. Confirm the field maps computation frequency

File Location

packages/twenty-server/src/engine/api/common/common-query-runners/common-merge-many-query-runner.service.ts

---

This issue was generated based on AI code analysis. The suggestions should be validated by a human before implementation.