Managing Postgres connections limits for a Django project (what are connections anyways?)

My questions involve Heroku but any Django developer here who has some experience with Postgres or other SQL-like databases may be able to assist.

Heroku limits Database connections in my “Hobby” service tier to 20. My $ heroku pg:info output is showing that my Postgres instance housing my prod content (mostly text) is at 4/20 connections. So I am well within my limit. Although I thought earlier today the number was 10. My first question is, when should I begin worrying about reaching my limit?

The larger question that I need an answer to I guess is what are database connections in general? Are Postgres connections a reference to:

  1. the number of Django Admin Dashboard users who can connect at the same time?
  2. the number of website visitors making requests to Django to retrieve data from Postgres concurrently in real time?

In my effort to answer my own questions, here are some Google search terms I have used so far:

  • ‘postgres connections’
  • ‘postgres connections heroku tier’
  • ‘postgres max connections’
  • ‘what are database connection limits’

According to the official Postgres wiki, they explain the max_connections feature in this way:

That doesn’t help at all.

IBM has a doc addressing how to fine tune and scale Postgres in the cloud. IBM introduces the principle of database connections in this way:

This doesn’t answer my questions either. I’m not sure what else I should be looking for to better answer my initial questions.

As far as Django is concerned, there’s some general information in the general notes section of the Databases docs. Let’s start there, and if you have more questions, feel free to ask.

Thank you. I will review the official docs and report back here soon with a solution.

I read the official Django doc you shared. It doesn’t really answer my initial questions very clearly. Next I Googled ‘connection limits postgres scale heroku’ which turned up a 7+ year old Heroku blog post which seems to have answered my questions quite nicely. I was originally mulling over the fact that ‘only’ 20 people can view my site at once. But that partially makes sense now since I am experimenting with the prototyping service category. Even for the most demanding Django/Postgres combo workloads and use cases, according to Heroku, the max number of connections is 500. Full stop. That still seems like not very much when a site like Instagram would serve hundreds of thousands (perhaps even one million or more) simultaneously. The architecture of cloud computing resource allocation is out of reach for me but the key takeaway here for deploying my tiny Django project is that I can simply leverage the official Heroku pgbouncer buildpack which will automatically handle the number of Postgres connections for me.

Having said all of that, I feel like I can answer my initial questions now:

I can decisively confirm that database connections are website visitors.

The answer to that question is “no”.

The answer there is “yes”.

@KenWhitesell: Can you confirm that the answers to my own questions are correct and accurate?

Here are some new questions for you Ken (or anyone else on these forums): What might happen when my server reaches and exceeds 20 web visitors? Will it crash? Will performance degrade immediately? Or just slightly with 21 or 22 connections and more drastically with 50 or higher connections?

No, technically that’s not true. The docs identify those cases where a connection is used. Also, connections are reused between visitors.

That is correct.

Yes, but the number there is going to be smaller than the number of concurrent visitors.

Assuming you have a number of worker threads / processes <= the number of connections, the request is held (paused) until one of the processes is freed up.

Keep in mind that each and every page or asset request is a separate request to the server, and the connection to the browser is closed after the response has been returned.
In general terms then, unless people are just clicking page after page as quickly as they can, people are spending the majority of time between requests. If a view is rendered in, say, 1 second, and they spend 10 seconds reading the page that was rendered, then your site can easily handle 200 concurrent users - and probably effectively handle 500 without any significant noticeable delays. (Those are very rough rule-of-thumb guidelines, but it’s a starting point for more accurate evaluations based upon your specific site.)