farmdev

The issue that I have with that attitude (as an experienced Python and Django developer) is that there's a lot more to it than just "swapping out Django's DB and replacing it with SQLAlchemy". You miss out on most of the infrastructure around Django's database stuff that makes it so easy and worthwhile to use.

For example, fixtures. In Django, you can include them in your tests and have it All Just Work(TM):

https://docs.djangoproject.com/en/dev/topics/testing/#fixture-loading

You can also use them outside of testing, too:

https://docs.djangoproject.com/en/dev/howto/initial-data/#providing-initial-data-with-fixtures

Fixtures in Flask/SQLAlchemy? Not so much - you have to roll your own (crappy) implementation:

http://farmdev.com/projects/fixture/using-fixture-with-pylons.html

http://flask.pocoo.org/mailinglist/archive/2011/3/6/flask-sqlalchemy-and-fixtures/

Also note that, while I'm picking on fixtures here, Django also has a bunch of other database related features, like introspecting a pre-existing database, and generating a bunch of Model classes from it. Combine that with South and you're 90% of the way there when migrating the data from a legacy system.

This has turned into a bit of a rant, but I've seen a lot of half-baked reimplementations in "pluggable" architectures of stuff which Django just gets right.