HN

Need help?
<- Back
Why we built yet another Postgres connection pooler

Why we built yet another Postgres connection pooler

levkk

Comments (40)

  • AdieuToLogic
    The fact that PgDog supports prepared statements[0] is a compelling feature in and of itself. This was a limitation of older versions of pgpool-II[1] thus disqualifying it in efforts where it otherwise could have been beneficial.0 - https://docs.pgdog.dev/features/connection-pooler/prepared-s...1 - https://www.pgpool.net/docs/4.7/en/html/
  • abrookewood
    Quick note to say that the article describing WHY you are different and why it matters was very well written. Congrats on the launch!
  • 27183
    It's awesome to see AGPL instead of the horrible BSL variants that have been going around.
  • rubenvanwyk
    What really interests me most is the sharding and the possibility of using this for multitenancy - is the hooks / plugin architecture sufficient so you can run a small sidecar to add shards or tenants to the TOML file dynamically? Would be a game changer.
  • petters
    > Since connection poolers reuse connections between clients, the connection state of one client “leaks” into the connection state of another.Wow this is very bad. This actually happens in typical Postgres setups?
  • khurs
    Any plans to add Query Caching for Selects?as per:https://www.pgpool.net/docs/latest/en/html/runtime-in-memory...
  • babayega2
    Is there a pooler handling schema switching in PostgreSQL? like something in front of django-tenant ?
  • inigyou
    Doesn't this NOTIFY performance fix mean that it isn't transactional any more?
  • jauntywundrkind
    Clickhouse also just put out a fun article on scaling pgbouncer too, talking about scaling out so_reuseport while not having to shard so harshly (a major limitation pgdog here is addressing via rewrite), https://clickhouse.com/blog/pgbouncer-clickhouse-managed-pos... https://news.ycombinator.com/item?id=48814152
  • mmakeev
    we moved our django app behind pgbouncer transaction pooling a few days ago and the surprise wasn't SET so much as queryset.iterator(). it relies on server side cursors, which don't survive being pooled, so we had to disable it everywhere and let it fall back to client side. also had to move statement_timeout out of the app's connection options into the pooler's own connect query, since libpq startup params just get silently ignored behind it.
  • Technical_Plant
    [flagged]
  • danielsmori
    [flagged]
  • fernando-ram
    [flagged]