Django makes it nearly trivial to switch:

* Email backend: https://docs.djangoproject.com/en/dev/topics/email/#defining...

* User model: https://docs.djangoproject.com/en/1.7/topics/auth/customizin...

* Authentication backend: https://docs.djangoproject.com/en/1.7/topics/auth/customizin...

* Databases

Django makes is very easy to write

* Views which extend from generic CBV and only need you to customize your CBV

* Custom template tags

* Wonderful admin pages: Its amazing what you can do with just Inline, list_display, list_search, list_filter etc. If you are willing to read through a bit of ModelAdmin class, then you will see it has nearly all hook points over ridable, though some it could do with a bit of documentation around ModelAdmin hook points.

When people say that `Django is not known about it's 'overridability'.`, they need to back it up with more data, because that not true at all, at least in 1.7

To be fair they were mostly recent additions.

What parts would you like to override that are difficult to do so?

Some people want to replace the ORM, but I find myself dropping into SQL in places where I need more advanced features. Django is sometimes chided for its simplistic ORM, but I've actually started thinking that if you are going to use an ORM at all, it probably should only be used for the more simple cases. Fortunately, the vast majority of queries in our codebase at Pathwright are pretty simple.

You need not be afraid to use SQL when you need to do something more advanced. You don't need to feel dirty about it. Postgres in particular can do many more things than any ORM is going to be able to cover 100%. Sometimes you can flat out do something much more efficiently than the ORM can with a simple SQL statement.

If you follow this line of thinking, I'm not sure there's a great reason to bother wedging SQLAlchemy into Django, if I'm just going to end up dropping down into SQL for the more advanced queries.

The ORM lets you write raw SQL with .extra: https://docs.djangoproject.com/en/dev/ref/models/querysets/#... and still get ORM objects back in return, or with .raw: https://docs.djangoproject.com/en/dev/topics/db/sql/ or just by manipulating cursors directly. Nothing in Django makes it harder to use raw SQL...

I agree, sure, you lose portability (or you can have a generic slower ORM case if it's that important) but dropping down to the SQL in corner cases is perfectly valid (and helpful)

For many cases, portability is a complete non-issue. For example, at Pathwright we chose Postgres for a bunch of reasons. We don't care about MySQL or Oracle or SQL Server. If there ever came a point where we had to make a switch for some reason, it wouldn't be horrible to make the necessary changes to the smaller number of places that we use SQL.

Of course, portability could be more of a concern if you are writing something that you are going to let customers run on their own hardware/environment. Though even then, I'm not sure I'd want to have to deal with supporting customers using every DB server that Django supports...