The ORM is bad because it is a poor abstraction of SQL. This manifests itself in several ways, the largest being little control over the SQL queries generated.

Here's a gist I made the other day demonstrating this. https://gist.github.com/jawnb/cd7a899cac5300c01709

The poor abstraction really causes problems when you need to do anything beyond the simplest of use cases. To achieve even modest performance gains, you're better off hand writing your SQL. Additionally, doing even the most trivial of trivial aggregate queries will also mean that you're hand writing SQL.

SQLAlchemy is light years beyond the django ORM in this regard.

Don't take just my word for it though, here's a talk Alex Gaynor gave saying the same things. https://www.youtube.com/watch?v=GxL9MnWlCwo

I think the most important difference between Alchemy and Django is the separation between the SQL abstraction layer and the ORM. There is no separation with django, making it very difficult to really get in there and make changes.

But I don't think this makes the django ORM bad. It is very easy for beginners to get up and running. It is very easy to understand the models and the query language.

As an FYI - 1.8 should make it possible to use .annotate() for constructs that aren't aggregates - like functions and extra select columns. You'll also be able to write more complex aggregates. It should give you greater control over your SQL, removing the need for .extra() in most cases (but not .raw()). It's what I've been working on recently: https://github.com/django/django/pull/2496

>The poor abstraction really causes problems when you need to do anything beyond the simplest of use cases. To achieve even modest performance gains, you're better off hand writing your SQL. Additionally, doing even the most trivial of trivial aggregate queries will also mean that you're hand writing SQL.

This isn't really a big deal - you can just hand-write your sql directly using .raw() and just pull out the corresponding result set and use it as you were doing before.

I've had to do what you're suggesting, but not a huge amount. Maybe 10-15 times on large, high scale projects.

SQLAlchemy is better but the number of times I have to break out of its abstraction layer are not enough for me to feel like I really have a desperate need to use alchemy instead. It's a minor inconvenience, nothing more.

Is actually one of the best components of Django. QuerySet objects and Custom Managers are really great for big projects

It's got better. When I first started using it you couldn't bulk save objects, each save was an individual query. It also loves to make lots of queries, especially in templates. I guess my true dislike stems from using SQLAlchemy, and realizing how awesome it is compared to Django's ORM.

I do love the relationship stuff - making a m2m field is super easy and it just works. Also manager/queryset extensions are super easy.

I haven't actually used SQLAlchemy, but I know it has a lot of features that would be extremely useful for django. I really like how it separates out the Core and ORM components.

I prefer djangos syntax for composing queries and defining models though.

The common criticism I hear is that it can't do everything, unlike SqlAlchemy. Fair enough, but the Django ORM is no doubt simpler to use than SqlAlchemy.

SQLAlchemy is designed for people who know SQL already and want a safe and convenient way to use it from Python.

The Django ORM is designed for people that want their Python data objects to be persisted to a back-end data store.

Both of these things have their place. The problem with the Django ORM is sometimes you need to do something slightly more complicated than what it supports and your back to raw SQL. These scenarios are really common, 90% of Django project have raw SQL in them.

SQLAlchemy uses the data mapper pattern whereas django ORM uses active record - that's the main difference. Neither one is really 'better', there are advantages to both approaches:

http://russellscottwalker.blogspot.sg/2013/10/active-record-...

The main advantage to django ORM in my opinion is 'less code', although it does create an excessive coupling between your persistence / model layer. Whether that is something you can live with or not is up to your project's requirements.

I'm pretty happy to work with both. Just don't make me use RoR!

I've got to disagree with the 90% figure. The vast majority of projects I've seen (which are typically pretty straightforward from a data modeling perspective) rely only on the ORM.

Maybe 5% of the Django projects I've been involved in contain raw SQL.