Django migrate row size too large

We’ve been using Django for years for our project. But moved away from using its migrations due to issues, a long time ago. We’ve recently begun moving back, but when I run "migrate ", I get a generic mysql error and no pointer to which table/model that caused it:

(1118, ‘Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs’)

I’ve read on stackoverflow, and other places, that I can change a setting in regards to our DB server.
But this doesn’t make sense to me, as we have a custom build_tables.sql file that generates all our tables and that works without this error.
There are 100s of models so reading “You have to change some columns to TEXT or BLOBs” wasn’t helpful from the MySQL error exception.

I’ve found the last table it made - by checking the DB Vs the
Worryingly, all tables made before have none of the “unique” keys. Is this normal? Id have thought that Django would make the tables with their keys in one go?

I can’t see anything explicitly wrong with the model/table it didnt make (and I assume broke at).

Does anyone have any ideas/pointers I could look at ?

How does django migrate work? It seems to do everything in passes?
Like it failed but created 90% of my tables. So I removed the “broken” table and ran again, this time it failed somewhere else, but still not creating all tables and now some do, and some don’t, have Keys


I don’t usually use MySQL and I’ve never seen this error - but if I were trying to diagnose something like this, I’d try -

  • adding the -v 3 parameter to get the most detailed logging available
  • try it with the --plan parameter to see what was intended to happen
  • run it under a debugger to see if I could find out exactly where the error occurred
  • try it against a totally new database to see if there was some inconsistency between the schema and what migrate is trying to do

All the key information you need about Migrations. Also, the source code is available if you really want to dive into it. (What I’ve done on rare occasions in the past is create a new virtual environment, and edited system packages to add print statements for me to follow along with what’s happening to try and figure out where things go wrong.)



Thanks for all the ideas!
I actually forgot you could get django to spitout the sql it is going to run. So I did that, and worked from there.

Turns out the issue was my DB was created with a COLLATE that isnt used by our other DBs and was an issue for creating tables with certain key lengths.
Once this was changed, everything worked fine.

I’m annoyed at myself for missing that I was creating this test DB with incorrect properties.

Thank you for reminding me about “-v 3”. What debugger do you use btw?

I’ve been using the debugging facilities within Visual Studio Code.