Why we built yet another Postgres connection pooler

Post by khurs » Tue, Jul 07, 2026, 11:21 PM UTC

tpetry wrote: post #23

khurs wrote: post #13

Earlier quoted context omitted.

>might bringt Postgres finally closer to vitess Supabase are launching a Vitess for Postgresql, they have hired the original creator of Vitess for it https://supabase.com/blog/multigres-vitess-for-postgres

And Planetscale (who is the current primary maintainer of vitess) is developing a Vitess for PostgreSQL. There will be a couple of production-grade PG vitess solutions the next months.

Post by khurs » Tue, Jul 07, 2026, 11:41 PM UTC

samlambert wrote: post #33

khurs wrote: post #32

Earlier quoted context omitted.

Looked it up, says 'Will be released as an open source project' but announcement was in July 2025 and no public repo yet which is strange, so time will tell if they will stick to this. https://planetscale.com/blog/planetscale-for-postgres#vitess... https://planetscale.com/neki ... Supabase one is open from start: https://github.com/multigres/multigres https://multigres.com/

We are already moving Neki customers into production. Nobody else is even close. PlanetScale doesn't spend our days yapping about what we are going to do. We just do it.

Post by samlambert » Tue, Jul 07, 2026, 11:43 PM UTC

khurs wrote: post #34

samlambert wrote: post #33

Earlier quoted context omitted.

We are already moving Neki customers into production. Nobody else is even close. PlanetScale doesn't spend our days yapping about what we are going to do. We just do it.

Congrats! The question was whether your previous statement about it being open source was still the case, or is it now going to be propriety?

Post by drdexebtjl » Wed, Jul 08, 2026, 1:02 AM UTC

SahAssar wrote: post #35

drdexebtjl wrote: post #31

Earlier quoted context omitted.

I was thinking of something that only exists at the pool level. Every new version of your app has the potential to change behavior in a way that would affect the previous version if the connection was recycled during a progressive rollout. But I don’t think I would want to create a real database user for every version of the app. I suppose the connection pooler could map versioned users to the same real user, and use…

> But I don’t think I would want to create a real database user for every version of the app. Why not? Database users are (usually) not expensive, and with groups you can give access to a group you just add the user to. Adding this logic to the connection pooler seems more complicated.

Post by fsuts » Wed, Jul 08, 2026, 1:55 AM UTC

HackerThemAll wrote: post #27

mmakeev wrote: post #2

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…

Using server-side cursors is a sign of bad design. You use the PostgreSQL server's resources as a cache when you're fetching and processing stuff row by row, which is very bad. Just get the data you requested in the first place in one go and do your stuff in your app. Or process all data on the server and then get the processed data in one batch as well.