Reject Django for database operations

[iszulcdeepsense]

Django is bad at handling connections to database. In particular, it doesn't close them properly. It is known of leaking database connections - see https://github.com/TheRacetrack/racetrack/issues/319

On one of our environments, 3 instances of Lifecycle used up to 200 connections and wanted even more. It caused exceeding max pool size which caused database connectivity to misbehave. According to the graph, at some point, one instance established 94 TCP connections.

We have to put an end to this.

This crazy amount of connections comes from the fact that every thread uses its own database connection (at least one + extra leaks). One replica of Lifecycle runs on up to 60 HTTP worker threads.

Let's switch to something else than Django for database connectivity. Perhaps doing raw SQL queries with shared psycopg conenction pool would be the best choice to make it simple and to control the number of connections in a reliable, predictable manner.

At this point Django is used for the following things:

• Reading & writing models to database tables - making SQL queries + Object-relational mapping
• Admin panel for managing models in the database - adding ESCs, adding permissions, etc.
• User management - passwords encryption, enforcing password policies, etc.
• running migrations after changing SQL schema of tables.

[anders314159]

So the problem was Django, and not Postgres being 'slow'? Or was it an unfortunate combination of the two?

Reading the above, I am in favor of removing Django database connectivity, but how many of the above functions from Django can we keep? I would prefer not to get into the habit of writing SQL queries,

[iszulcdeepsense]

So the problem was Django, and not Postgres being 'slow'? Or was it an unfortunate combination of the two?

In a sense, it was both. On prod server, it was mostly due to other apps makind Postgres slow. On test server it was Django killing the database limits.

I am in favor of removing Django database connectivity, but how many of the above functions from Django can we keep? I would prefer not to get into the habit of writing SQL queries,

Maybe we can keep Django for other stuff, but at least use something else for crucial queries. I wonder if that can cause even more connections though. It's hard to find the drop-in replacement for all of the reasons we're using Django.