211–220 of 452 posts
Earlier quoted context omitted.
My experience of both is that MySQL is easier for developers, PostgreSQL is easier for sysads. That was true in 2012; dunno if it still applies though.
>MySQL is easier for developers Except that search doesn't work, because all text is in latin1 encoding.
Earlier quoted context omitted.
Yeah but you don't need to worry about your data existing. MySQL has been known to silently fail the one job of a DB.
Not in around 15 years. You're thinking of when MyISAM was the default storage engine for MySQL. It has been InnoDB for over a decade. InnoDB is very reliable - I've never had a single data loss incident in all that time, and I've managed some very large (PB-scale) and active databases. Postgres is definitely more difficult to administer.
i ll tell you why from my end. I installed Postgres14 via homebrew many years ago on my Apple M1 mac mini. I searched a lot on how to "upgrade" this installation but found nothing. I have a few databases running with data on it which I can't afford to lose if something goes down for more than 1 hour. I wish someone would guide me on how to actually install a newer postgres such as v17 without breaking an existing v14…
This kind of sounds like a Homebrew issue…? I’ve run multiple variants of PostgreSQL on my MacBook under MacPorts. Can’t even remember the last time I thought about it, to be honest.
% brew search postgres
==> Formulae
check_postgres postgresql@12 postgresql@15 postgrest
postgresql@10 postgresql@13 postgresql@16 qt-postgresql
postgresql@11 postgresql@14 postgresql@17 postgis
Because the actual process of upgrading Postgres is terrible. I say this as someone who absolutely loves using it, but the actual process of upgrading Postgres is something that takes significant downtime, is error-prone and you're often better off just dumping all the databases and reimporting them in a new folder. (A good idea in general since it'll vacuum and compact indexes as well if you do it, combining a few m…
But obviously this is not suitable for all use cases. I don't know why pg doesn't invest in this sector.
Earlier quoted context omitted.
> Doing similar for my Linux VPS with only a terminal is much more complicated. Debian/Ubuntu: sudo apt update sudo apt upgrade Fedora/RHEL: sudo dnf update Arch: sudo pacman -Syu Alpine Linux: apk update apk add --upgrade apk-tools apk upgrade --available Of course, if the package you need isn't available in the standard repos, then you'll need to look elsewhere (e.g. PPAs or third party repos). There's also options…
Sorry I wasn't very clear, it's totally on me. On average, the experience of upgrading/managing packages is obviously much better than Windows. I meant to say in certain cases (like the `unzip` example I mentioned above), when the system's build-in package manager fails, I seem to not be able to find alternatives like what I did on Windows (just find the piece of binary I want and manually install it). I to this day…
Earlier quoted context omitted.
Also: 5. If your IT department is spread thin already and that old version is running fine, the incentive to potentially create more work for yourself is not gigantic.
One of the first laws of the universe that a good engineer learns is: Do not fix what is not broken. And no, being old is not broken.
That doesn't mean "upgrade recklessly," but it does mean you should know _why_ you're either upgrading or _NOT_ upgrading. That's your job, much more than the act of upgrading itself.
Unpublished vulnerabilities in old software are not a hypothetical. And very old packages are usually broken, just coped with at the expense of significant lost opportunity cost - or because the failure is a combination of rare and impactful that means once it happens everyone is out of job anyway.
Seriously, I've yet have to encounter a sysadmin using that old, silly adage at me and not later have to admit I was right.
Edit: so no, you don't stay on an ancient version of the database because "it's not broken." You're staying on it because _the upgrade process itself_ is so broken you're terrified of it.
Earlier quoted context omitted.
So the real question is, why is the upgrade process so incompetently designed, and why has no one fixed this?
My opinion is Postgres was designed by software developers for software developers. The split on “which relational database to use” in my career has almost always been perfectly split between SWE vehemently demanding pgsql for the feature set, and the sysadmins having to support maintenance and production availability preferring MySQL. One of the few things I’ve enjoyed with the move into devops and companies forcing…
Earlier quoted context omitted.
One of the first laws of the universe that a good engineer learns is: Do not fix what is not broken. And no, being old is not broken.
The entire field of maintenance engineering would like a word. Over longer periods of time it's vastly cheaper to regularly fix things even before they break, and software is no exception. Amongst other reasons: - Performing regular upgrades is an easy and cheap way to maintain a healthy knowledge base about the system. It's always easier to fix a system that is well understood than a black box which nobody has touch…
I mean I think it's because maintenance is so unglamorous. So when it happens and everything doesn't collapse, nobody remembers and starts asking why we even do it (and then sysadmins and middle management suddenly aren't a thing, and companies and IT become exactly as fragile as anyone with _actual_ understanding of management would expect).
Meanwhile when regular maintenance fails in progress, it often ends up in the news with a body count attached.
One of my favourite podcasts has a running joke that you should never do maintenance (because so many industrial disasters happen during it). Of course the bias is the point of the joke - and usually the reason things went bad is because either the maintenance was neglected until that point, or the engineering picked Postgresql, I mean, didn't consider the necessity of maintenance.
Because the actual process of upgrading Postgres is terrible. I say this as someone who absolutely loves using it, but the actual process of upgrading Postgres is something that takes significant downtime, is error-prone and you're often better off just dumping all the databases and reimporting them in a new folder. (A good idea in general since it'll vacuum and compact indexes as well if you do it, combining a few m…
So the real question is, why is the upgrade process so incompetently designed, and why has no one fixed this?
So even if it's available these days, the amount of people still subjected to upgrades from older version still leaves an impression that it's really bad.