How people are running any RDBMS in prod — but especially Postgres - and not using a connection pooler with the capability to pause incoming connections is beyond me.
The entire “how do we drain connections” issue described in TFA becomes trivial, as does gradually raising the amount of incoming connections, let alone the load advantages from multiplexing the client connections.
How people are running any RDBMS in prod — but especially Postgres - and not using a connection pooler with the capability to pause incoming connections is beyond me.
The entire “how do we drain connections” issue described in TFA becomes trivial, as does gradually raising the amount of incoming connections, let alone the load advantages from multiplexing the client connections.
Separate high-frequency operational state from large, flexible, searchable metadata. It is bad data models that don't scale
15,000 database connections seems like a lot. Is that a scale Postgres supports very well?
That’s well beyond what a stock Postgres server would reasonably handle
> with an unusually large load we surpassed our provisioned IO on the underlying volume
Sounds like they could have benefitted from Aurora's storage model (though there are reasons not to use it, too).
Don't reboot the db during your next outage.
Yeah. This is why we have connection pooling.