I love SQLAlchemy - it's an amazing piece of software, and I use it often. So why wouldn't I argue for Django to switch? * I love Django's ORM, too. It's far s

I love SQLAlchemy - it's an amazing piece of software, and I use it often. So why wouldn't I argue for Django to switch? * I love Django's ORM, too. It's far simpler, much easier to teach to new users, and results in code that "scans" better. It's only able to achieve that ease-of-use by sacrificing features -- a classic trade-off. Neither approach is more "right." * SQLAlchemy didn't exist when we wrote Django. Yes, you've just dismissed that argument, but I can't. There are thousands -- probably tens of thousands -- of Django sites out there, and I'm not so quick to break backwards compatibility just for the new shiny. * Finally, and most importantly, SQLAlchemy has some fundamentally different goals than Django's ORM. SQLAlchemy aims to provide an API to represent SQL in Python. Django aims to provide a persistance layer for objects. The difference between these philosophies is important: the use of a relational database is almost an implementation detail for Django, but it's SQLAlchemy's raison d'être. This isn't just academic: it means, for example, that Django's ORM will one day support non-relational databases (work here's already begun), but SQLAlchemy won't.