`migrate dev` is too slow when migrations directory is large

Bug description

Hello, Prisma team, thanks so much for this amazing tool 👐

I have been using Prisma Migrate in production for several months now. My schema has suffered a lot of changes and thus my migration directory is large (129 migrations as of now). Nowadays every time I execute migrate dev, the command takes a significant amount of time to be created. Screenshot below

It took around 5 minutes in these cases, even if no schema changes were required.

How to reproduce

I assume you can reproduce it with any Prisma project with 100+ migrations

Expected behavior

I’d like it to take no more than a minute, just like the early days of using Prisma Migrate. Or as an alternative, I’d like to get some indication of the progress it is making (similar to migrate reset, for example).

An option for me is also to delete ‘reset’ the migration history and start fresh without losing any data, I rarely use old migrations for anything. It would be useful to get an official workflow for his (maybe it would involve prisma introspect?)

Prisma information

This problem occurs on a Prisma project with 126 migrations and 24 MySQL tables.

Environment & setup

• OS: Debian KDE Neon
• Database: MySQL 8.0
• Node.js version: 14.X

CPU info

Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 43 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 23 Model: 24 Model name: AMD Ryzen 5 3400G with Radeon Vega Graphics Stepping: 1 Frequency boost: enabled CPU MHz: 1400.000 CPU max MHz: 3700.0000 CPU min MHz: 1400.0000 BogoMIPS: 7386.19 Virtualization: AMD-V L1d cache: 128 KiB L1i cache: 256 KiB L2 cache: 2 MiB L3 cache: 4 MiB NUMA node0 CPU(s): 0-7

Prisma Version

prisma                  : 3.8.1
@prisma/client          : 3.8.1
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
Migration Engine        : migration-engine-cli 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine    : introspection-core 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary           : prisma-fmt 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Default Engines Hash    : 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f
Studio                  : 0.452.0

[floelhoeffel]

We now have some docs on squashing migrations that might be helpful: https://www.prisma.io/docs/guides/database/developing-with-prisma-migrate/squashing-migrations

[janpio]

Hey @arvindell (and @motdde if you happen to work at the same company), can you maybe try to run npx prisma migrate dev --skip-generate so we get a cleaner view on the duration the actual migration takes? I suspect it will not make a huge difference - especially not compared to the total of 5 minutes, but still.

Additionally, this command might also be helpful to get some interesting debugging output in the terminal that might help us understand what is happening: DEBUG="prisma:migrate*" npx prisma migrate dev --skip-generate. Paste the full output if you can.

And for bonus points and the best solution, can you maybe share your schema and migrations with us so we can reproduce this? We can of course try to create something like this manually, but it would be super convenient if we could just use your migration history to see how that performs on our machines and then jump in what actually takes all that time when you run the command. (My email is [e-mail] and if needed we can of course also set up an NDA between our companies quickly - we have templates ready for that.)