The method of working out which migrations to run, going off the highest timestamp in the database is too basic for real development scenarios.

Typically you will have different developers working on feature branches, and adding migrations as they go along with their development. Whilst a development branch is worked on, other branches may be merged and released. This means that when a branch is merged in it will likely have migrations which have an earlier timestamp than those that have already been ran, but those migrations still need to run to support that feature.

The method of working out which migrations to run should inspect the files in the migrations directory(s) and check them against the ran migrations to see which still need to run. It should not go off a latest timestamp / version alone.

As it is, with this system, we need to rename all our migrations post merge and before rollout to give them a later timestamp / version that what is current. When you could possibly have dozens of migration files, this is onerous.