My first instinct was to scream "just use a CMS", but there are obvious advantages to this technique, so here are my thoughts to make it less hacky if someone e

My first instinct was to scream "just use a CMS", but there are obvious advantages to this technique, so here are my thoughts to make it less hacky if someone ever intends to run that in production. - the most obvious one I don't see mentionned is that you should use a separate database than your main one for all the generated tables. Pretty sure it would save on operational headaches. - it would probably be useful to generate all the Python code that could be used for making migrations, if only for debugging purposes - understand early on which Fields you want to use with which options. I wonder if ForeignKeyField would be possible. That would be a great feature, but probably bring headaches. - obviously, try to submit a PR to Django for the migrations loader hack, maintaining Monkey-patchs is troublesome All in all, it's a pretty cool hack, but even with those modifications, I'd still be very wary to use that in production instead of battle-tested alternatives, unless you have a use-case that really warrants having full-blown SQL schema for your dynamic data. Edit: on second thought, I can think of a use case where using that in a CMS would have saved me troubles (at least different tables for different Models). When you have a production site receiving Model A data (for example, your clients orders) AND you want to edit Model B data (for example, your site dynamic pages), you can't do that with EAV all in a single table, but with using dynamic models, you could just copy the Model B data, or even go with more complicated scripts.