3 ms·
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 lik
by fabian2k 3y ago
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 3y agoI 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 3y agoI 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 3y agoEach 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.