[aynyc]

I've been using Django on and off at work for the past few years. I really like it. That being said, I still find its ORM difficult. I understand it now that since it's an opinionated framework, I need to follow Django way of thinking. The main issue is that at work, I have multiple databases from different business units. So I constantly have to figure out a way to deal with multiple databases and their idiosyncrasies. I ended up doing a lot of hand holding by turning off managed, inspectdb and then manually delete tables I don't want to show via website or other reasons. For green webapps we have, django is as good as it gets.

[BowBun]

Agreed, and their DB migration workflow leaves much to be desired. By not storing a schema/DB state alongside code, Django depends on the current DB state to try and figure it out from scratch every time you run a DB command. Not to mention defining DB state from model code is inherently flawed, since models are abstractions on top of database tables. I much prefer the Rails way of composing migrations as specific DB instructions, and then getting models 'for free' on top of those tables.

[JodieBenitez]

Do you use Django's multiple databases support ? (https://docs.djangoproject.com/en/6.0/topics/db/multi-db/)

[aynyc]

Yes, we have to in order to use a lot of the features. The core issue for us is really the way Django assumes code represents database state. In normal webapp where the application has full control of the database, that's a good idea. But our databases are overloaded for simple transactions, analytics, users managements, jobs and AI. Business uses the databases in various ways such as Power BI, Aquastudio, etc.. Django app is actually a tiny part of the database. As you can imagine, we duck tape the heck out of the databases, and Django goes bonkers when things aren't matching.

[dontlaugh]

I've used Aldjemy (https://github.com/aldjemy/aldjemy) on a small project and it worked pretty well for allowing me to compose the fairly complex queries needed that the Django ORM couldn't do.

[sgt]

Also don't underestimate setting up e.g. views or materialized views even that you can use through the ORM to query. It helps a lot and allows you to combine fine tuning SQL with ease of use through Django, and get a lot of performance out of it. Just remember to create them in the migration scripts.

[aynyc]

Any docs? Django migration is a HUUGE pain point for us.

[luxcem]

I've been using Django for the last 10+ years, its ORM is good-ish. At some point there was a trend to use sqlalchemy instead but it was not worth the effort. The Manager interface is also quite confusing at first. What I find really great is the migration tool.

[formerly_proven]

Since Django has gained mature native migrations there is a lot less point to using SQLAlchemy in a Django project, though SQLAlchemy is undeniably the superior and far more capable ORM. That should be unsurprising though - sqlalchemy is more code than the entire django package, and sqlalchemy + alembic is roughly five times as many LOC as django.db, and both are similar "density" code.

[melvinroest]

Maybe this shows my data analyst tendencies, but why not use SQL?

[aynyc]

That’s what we do now. But it gets repetitive and not leveraging Django core features.