[masklinn]

> Improved transaction management¶

> Django’s transaction management was overhauled. Database-level autocommit is now turned on by default. This makes transaction handling more explicit and should improve performance. The existing APIs were deprecated, and new APIs were introduced, as described in the transaction management docs.

> Please review carefully the list of known backwards-incompatibilities to determine if you need to make changes in your code.

> Persistent database connections¶

> Django now supports reusing the same database connection for several requests. This avoids the overhead of re-establishing a connection at the beginning of each request. For backwards compatibility, this feature is disabled by default. See Persistent connections for details.

[mbell]

It's hard to imagine using an ORM for anything high volume that just got around to adding (still very limited) connection pooling. I'd tend to think anyone overly concerned with performance would use SQLAlchemy, if they use any ORM at all.

[mhurron]

> I'd tend to think anyone overly concerned with performance would use SQLAlchemy, if they use any ORM at all.

Or they did connection pooling outside the development framework.

[collyw]

right tool for the job. Djangoś ORM is great for simple stuff. And it works with the admin interface (which is worth a lot). If You need something complex enough, use raw SQL.

The admin was too much to give up to swap the ORM to SQLAlchemy for me.

[ingrownpsyche]

I think a lot of people might've been using an external connection pooler, eg pgpool.