[fabian2k]

What exactly do you want to scale? But in the end the answer is likely "connection pooling", either integrated in the application or with a dedicated pooler like PgBouncer which this article is about.

For Postgres a good way to scale is to just use a bigger server. You can get a lot of very fast storage and lots of CPU cores inside a single server today. And if that isn't enough you're far, far into territory where you can't give generic answers and it depends a lot on your specific use case and what you do with that database.

[sidcool]

I mean let's say I have to support 10000 updates per second and 100000 reads per second. Surely 500 connection pool won't suffice.

[emilsedgh]

I don't think 10K updates per second are really that difficult for the db (Unless you have locking issues).

But at that point your reads should be probably be sent to read-only replica's. So you write to a master but all your read-heavy apps and queries run against replicas.

[jtc331]

Each of those reads may only be 1ms, which would translate into only 100 connections needed.

So the workload you describe — without more detail — may in fact be just fine with that connection count.

But plenty of people also run Postgres with well above 500 max connections.