Dogshit is overstating it. It is much better than what was typically used before.
Nah, "dogshit" is accurate. Words of adequate offensiveness have yet to be devised in English to describe git's competition, though. As I said, it's better than the rest, but that doesn't stop it being dogshit.
I've been reading about pg-promise and pg-listen for a full-fledged messaging implementation, this is absolutely amazing.
Very cool stuff for sure. Firebase can fuck right off.
PostgreSQL can do so much outside-the-box shit you wouldn't believe, including a lot of stuff people normally go apeshit "scaling out" a Redis or RabbitMQ deployment for where an existing PostgreSQL instance could easily do the job with room to spare and little-to-no performance difference.
Wait until you start screwing around with native JSON document handling and realize PostgreSQL is a better MongoDB than MongoDB.
It would have never occurred to me to run Postgres dockerized... I was under the impression that it should run on bare metal, as God intended.
PostgreSQL is best managed by things like ansible or terraform for actual installation and initial setup, on bare metal as God intended (as you say). Docker introduces a notable, measurable and inescapable network bottleneck. On Kubernetes, it's even worse (upwards of 30% on identical hardware depending on which network snap-in and service mesh you use, and to my knowledge they still haven't fixed it, and likely can't, since mega-hyper-high-speed networking is the purview of dedicated network/switching chips, not software-defined NICs). I've seen bare-metal single-node PostgreSQL instances outperform "clustered" PostgreSQL on Kubernetes just from the overhead being so overwhelming. Maybe
eBPF can eventually catch up, but it's not there yet.
If you must Dockerize it, the advise at the start of that message is accurate -- roll your own image instead of relying on the default. It's surprisingly easy to do, and anyone using Docker in production must (IMHO) be well-versed in Dockerfile and docker-compose.yml syntax, be very familiar with their intricacies and be experienced in creating custom images, so this
shouldn't be a "big ask" to begin with anyway.
Docker is a very useful tool, but it's spawned a fresh generation of lazy+incompetent sysadmins (a good sysadmin is lazy but
competent -- knows his shit well enough to automate it so he never has to do the same thing twice). "Oh just throw it away and spawn a new one lol" is indeed a useful approach ...
sometimes ... until you have an ailing system in production that need to diagnose
while it's sick. Then you're stuck shelling into a deliberately crippled, tool-less environment often with little more than /lib, /usr/lib, plain /bin/sh and some application binaries, to diagnose problems.
Any PostgreSQL upgrade should involve exactly one moving part at a time, so the updated container image should be identical in all ways to the old one
except for the PostgreSQL binary. If something as basic as glibc gets updated as a dependency during that process, you might as well get pg_dump started sooner rather than later because you'll eventually conclude a dump+restore is the best way forward anyway. You're often honestly better off standing up a fresh instance of the new version and replicating into it (as a slave, with the older version the master) and hot-swapping it into live status once the data's migrated; that's about the only way to avoid downtime during major version upgrades (especially on garbage like AWS RDS Aurora; and they're all too happy to charge you double for that extra capacity during the replication stage).
It is
not well-suited to the Docker philosophy of just "replace the container to upgrade or if something breaks." The on-disk format is guaranteed never to change over minor version updates, but the trade-off is it's also almost always going to change across major releases for various reasons (reliability, durability and performance, in that order), which makes major version upgrades non-trivial and that goes against "the Docker way." A good sysadmin or devops engineer is suitable for PostgreSQL, but a dedicated old-school DBA is better.[/url]
ETA:
Holy fucking shit. The most
recent commit removes a secret token that was getting baked into the CI/CD pipeline every time publicly. Have you just discovered the ultimate jeet repo? "Vibe coded," leaking secrets in CI/CD, NSA-adjacent... the mind boggles:
Jeet coder said:
ci: drop the access token from the libghidra checkout
libghidra is a public repository, so the checkout needs no credential. The explicit token resolved to an empty value and failed every job before configure ran.
