What is an effective way at handling the issue of Postgres allocating significant memory when it forks a new process?

Question

I've seen many articles and videos that say things like the following about Postgres over MySQL.

Postgres allocates a significant amount of memory (about 10MB) when it forks a new process for each connection. This causes bloated memory usage and effectively eats away at speed. Thus, it sacrifices speed for data integrity and standards compliance. For a simple implementation, then, Postgres would be a poor choice! - Sumo Logic

Every time I read that or hear that somewhere, there's no context about what it really means or if there is a way to handle it. What is are specific way to deal with that type of problem in PostgreSQL? Is this overcome by using connection pools?

Answer 1

Interesting to hear that 10MB is "a significant amount of memory".

A database is not a web server, which is optimized for serving lots of short-lived connections. A PostgreSQL connection loads cached catalog data for efficiency.

That is why you use a connection pool, so that all your short database requests are handled by a small number of persistent database connections.

I doubt that this is specific to PostgreSQL – other databases benefit from connection pools as well, and some even have one built into the server. So I would see the statement you quote as hate speech from a competitor who cannot think of anything better than reiterating the old myth that PostgreSQL is slow and complicated.