3 ms·
Even without pgbouncer postgres uses long lived connections (and long lived processes) . So bad example. Uber famously switched from pg to mysql because their
by Tractor8626 1y ago
Even without pgbouncer postgres uses long lived connections (and long lived processes) . So bad example.
Uber famously switched from pg to mysql because their SWEs couldn't properly manage connections
- anonzzzies 1y agoWas that the only reason? In our last testing (2021), on the same hardware and for our specific case (a billions of records database with many tables and specific workfloads), mysql consistently left postgres in the dust performance wise. Internal and external devs pointed out that probably postgres (or rather, our table structures & indexes) could be tweaked with quite a lot of work to be faster, but mysql performed well (for our purpose) even with some very naive options. I guess it depends on the case, but I cannot justify spending 1 cent (let alone far more as we have 100k+ tables) on something while something else is fast enough (by quite a margin) to begin with...