Live data from Hacker News

Why we built yet another Postgres connection pooler

pgdog.dev

71–74 of 74 posts

Re: Why we built yet another Postgres connection pooler

#71

Can someone explain it to me like I am 5. Why did postgres win vs mysql? I don't know many companies at scale that use postgres. Slack, youtube, etc all use a mysql based sharding system https://vitess.io/ . I thought the war was lost for postgres, but it seems to keep going. License issues? (Disclosure, I manage 'a few' mysql vms).

Maybe it's because Postgres is easier to write extensions for? I do think MySQL is still used more widely, but since people on HN and other hacker/tech circles write extensions, you hear about Postgres more. Those extensions also increase Postgres's actual usage, like I know people who only know about Postgres because of PostGIS.

Regardless of popularity, idk, Postgres feels nicer to use for me.

n.b. PgDog isn't an extension

Re: Why we built yet another Postgres connection pooler

#72
post #18

Earlier quoted context omitted.

Handling cursors is tough - they are very much session-level objects, so even if we, say, pinned your client while it uses that cursor, which would work, that would decrease the performance of connection pooling overall. So, what's better, breaking your app initially so you know to remove that feature, or letting it work silently while the connection pool isn't 100% in transaction mode? Tough call.

Which one did you pick?

Pin the client temporarily. I'm assuming that our users know what they are doing. I could be wrong, but so far so good.

Re: Why we built yet another Postgres connection pooler

#74
post #3

> 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?

”typical Postgres setups” do not include connection poolers to begin with, this is not a Postgres issue.
Post reply on HN