# django-fastmig, makes \`migrate\` several times faster

**URL:** <https://forum.djangoproject.com/t/django-fastmig-makes-migrate-several-times-faster/45796>\
**Category:** Show & Tell\
**Created:** [August 18, 2026, 2:24pm UTC](https://forum.djangoproject.com/t/django-fastmig-makes-migrate-several-times-faster/45796 "2026-08-18T14:24:49Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![viktor2097](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/viktor2097/32/33142_2.png) [@viktor2097](https://forum.djangoproject.com/u/viktor2097)\
**Post date:** [August 18, 2026, 2:24pm UTC](https://forum.djangoproject.com/t/django-fastmig-makes-migrate-several-times-faster/45796/1 "2026-08-18T14:24:50Z")

</div>

Released an experimental package making `migrate` much faster in large projects. Especially useful if you do `pytest -create-db` frequently, or run reverse migration testing in CI. Django’s own test suite passes with fastmig. Also tested on a 8 year old project with multiple revisions and migration squashes over the years.

Made it to speed up my own testing being bottlenecked by -create-db.  
There’s a link in readme related to forum posts which discusses slow migrations.

If you give it a try (and have many migrations) feel free to share if you see any big performance improvements, or small 😉

> **[GitHub - viktor2097/django-fastmig: Experimental drop-in add-on that makes Django...](https://github.com/viktor2097/django-fastmig)**
>
> Experimental drop-in add-on that makes Django \`migrate\` several times faster on large projects without changing the SQL it executes.

---

<div class="post-metadata">

**Author:** ![adamchainz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/adamchainz/32/26_2.png) [@adamchainz](https://forum.djangoproject.com/u/adamchainz)\
**Post date:** [August 18, 2026, 8:27pm UTC](https://forum.djangoproject.com/t/django-fastmig-makes-migrate-several-times-faster/45796/2 "2026-08-18T20:27:23Z")

</div>

Thanks for the work here Viktor, and linking back to [Very slow migrations with large numbers of tables](https://forum.djangoproject.com/t/very-slow-migrations-with-large-numbers-of-tables/29038) .

I think this is a valuable step forward on improving the slow migrations problem. You’ve described things well in your README, showing a clear understanding of bottlenecks.

Do you think you’ve found anything that could be applied to Django as an orthogonal step to @charettes 's [model state ticket](https://code.djangoproject.com/ticket/29898) ?

---

<div class="post-metadata">

**Author:** ![Louis2608](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/louis2608/32/33307_2.png) [@Louis2608](https://forum.djangoproject.com/u/Louis2608)\
**Post date:** [September 8, 2026, 11:03am UTC](https://forum.djangoproject.com/t/django-fastmig-makes-migrate-several-times-faster/45796/3 "2026-09-08T11:03:42Z")

</div>

Shaving time off pytest --create-db on old codebases with huge migration histories is a massive win for CI builds.

Running this on an 8-year-old project while passing Django’s test suite is a huge green flag. How are you bypassing the usual migration tree overhead under the hood without altering the generated SQL?

Definitely spinning this up in dev today to test the speedup. Awesome work!