Keeping in mind I'm referring to Django years ago, as I dont know how many of these limitations have since been lifted, the Django admin was able to be successf

Keeping in mind I'm referring to Django years ago, as I dont know how many of these limitations have since been lifted, the Django admin was able to be successful because Django itself only allowed a narrow subset of database constructs to be modeled in the first place. You had tables with single-column primary keys only, and then you had simple one to many, many to one, many-to-many, and their "generic foreign key" thing, and IIUC that was it. This narrow band of possible database configurations made it easier to put an admin on top of (and also to generalize into DB migrations). There are "django-admin" style tools for SQLAlchemy (or at least there were, back when people had the notion that "the Django admin" was why Django was successful), but they have a hard time being able to generalize to SQLAlchemy's capabilities for things like table inheritance, custom join conditions, composite keys, etc. Our users, when they build out their database schemas, are throwing the whole kitchen sink in there and producing a much more personalized kind of product that does not lend itself as well to a generic CRUD gui. Nor do a lot of SQLAlchemy users really want such a thing, since they will have these very particular types of models with lots of nooks and crannies that they'd prefer to code up themselves. The SQLAlchemy approach is a lot more schema oriented whereas the Django one strikes me as intentionally narrowed for simplicity.