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?

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.