Postgres locks do not scale

(recall.ai)

12 points | by timetoogo 1 day ago

6 comments

  • sgarland 3 hours ago
    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.

  • d4v3 3 hours ago
    Separate high-frequency operational state from large, flexible, searchable metadata. It is bad data models that don't scale
  • CubsFan1060 3 hours ago
    15,000 database connections seems like a lot. Is that a scale Postgres supports very well?
    • jbonatakis 2 hours ago
      That’s well beyond what a stock Postgres server would reasonably handle
  • hylaride 3 hours ago
    > 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).

  • nosefrog 2 hours ago
    Don't reboot the db during your next outage.
  • tony_cannistra 3 hours ago
    Yeah. This is why we have connection pooling.