Bitbucket implements merging of pull requests using git-merge; however as of Git 2.38 an alternative exists, it is now possible to use git-merge-tree and git-commit-tree to achieve the same goal. It would be beneficial to use this new approach for Bitbucket instances running Git 2.38.0 or later.

This will achieve a significant increase in performance since while git-merge needs to read/write the index and working tree, git-merge-tree does need to do this, in fact it can operate on a bare repository. Some experiments I've performed using a huge repository shows a decreasing in merge time from 17s using git-merge in Git 2.37 to 0.1s using git-merge-tree plus git-commit-tree in Git 2.38.

A similar change was previously made in the codepath where Bitbucket determines mergeability of a pull request (try-merge): https://jira.atlassian.com/browse/BSERV-13691

Side note:
Implementing this sooner than later is perhaps important because in Git 2.38 an unrelated bug fix results in an increase in the run time of git-merge: https://github.com/git/git/commit/034195ef927bcfc348a69672494f3781e8f5c093
This bug fix involves adding a step to restore the index and working tree to the pre-merge state. Testing with the same repository above shows an increase in time to run git-merge from 17s with Git 2.37 to 31s with Git 2.38. Furthermore, the peak memory usage was slightly higher in Git 2.38 as a result of the additional save_state step. This bug fix only results in slower git-merge, it does not impact the performance of git-merge-tree since the later does not use the index or working-tree.