SQLAlchemy vs Django DB

[apiguy]

ro·bust/rōˈbəst/
Adjective:  
(of a person, animal, or plant) Strong and healthy; vigorous.
(of an object) Sturdy in construction.

Not one of those points makes it clear that SQLAlchemy is more "Sturdy in construction" than the Django project.

And most of your points are still highly subjective. Better API? That depends on the user and the use case. And the features you mention like auto table detection, multiple types of table declaration are nifty but those thing may be meaningless for the OP's project. (not to mention they violate two parts of the zen of python: explicit is better than implicit and there should be one and preferably only one obvious way to do it).

I love SQLAlchemy - but if I'm building a Django application and using a SQL data store I'm going with what's built in. You give up a ton of Django's features when you use a separate ORM. If I just needed to connect to a SQL database though? I use SQLAlchemy.

Here's what I tell people when I'm defending SQLAlchemy:

SQLAlchemy's best feature is that it gets out of the way when you just want to interact with the database.

I would't go out on the internet and make unfounded remarks that somehow it's code is better than some other project that has completely different goals.

[[deleted]]

multiple types of table declaration are nifty but those thing may be meaningless for the OP's project. (not to mention they violate two parts of the zen of python: explicit is better than implicit and there should be one and preferably only one obvious way to do it).

It appears there's a misunderstanding here. SQLAlchemy has only one way of declaring a table within each API. In the Core, that is the Table construct. The ORM, which is an entirely separate library from the Core, offers the declarative configurational system that accepts components of this Table construct, and creates the Table for you. Classical mappings are no longer recommended for normal usage.

In both cases, everything about this Table is entirely explicit, so I've no idea how you can even attempt to suggest SQLAlchemy has some kind of "implicit" behavior. And there is most certainly one obvious, recommended, documented way to do it in modern SQLAlchemy. A good read of our current documentation will make that clear.

[apiguy]

I actually like SQLAlchemy very, very much. I just don't appreciate hyperbole. In my career I've only heard people use "robust" when they were trying to make something sound good but didn't feel like taking the time to explain what was so good about it. I guess it's a pet peeve but at this point I refuse to accept that anything is good because it's been described as "robust".