Fair. I picked two instances that had long been personally painful with MySQL and didn’t exist when I finally fled to greener pastures.

There are far more examples than just those two though. :)

Sure, and there are also plenty of examples of things MySQL can do that Postgres can't.

There's no silver bullets in software or databases, no "one size fits all". Just various trade-offs between different design decisions.

I mean, for most mature ecosystems / technology stacks I think the “no one size fits all, just strategic design trade-offs” theory largely holds true as an objectively accurate account of the “choosing the best tool“ situation ….

but IMO, I think it’s worth noting that occasionally, some rare unique and functionally superlative technology comes along that in practice transcends every alternative from the onset and indefinitely going forwards, sometimes even at a more prominent scale than the MySQL / Postgres projects topic of discussion (which are not small by any means).

something maybe like Git, most immediately comes to mind, as an example of the de-facto standard for distributed VCS basically since … 2005* when Linus decided to create it?

edit: not 1995

> something maybe like Git, most immediately comes to mind, as an example of the de-facto standard for distributed VCS basically since … 1995 when Linus decided to create it?

hot take. might be the most popular, maybe even by a large margin, but I think you'll find a good chunk of people who have actually tried different VCSs don't think it's the best.

Yah, I think that’s probably true. But that’s also hard to reconcile with the reality of the adoption trending consistently away from any alternative and only towards Git. And “large margins” are indeed pretty objectively the case (from the largest developer surveys the breakdown 10 years ago was like 70% Git to everything, growing to ~95% in 2022). Usually the phenomenon you’re describing, leads to other alternatives becoming more popular not less (even if the most popular standard continues to eclipse the field. Here is would seem these highly likable alternatives for those who took the plunge are nevertheless dwindling into irrelevance…

I suspect the die-hard proponents of Mercurial, or SVN, or whatever else, these few pagan heretics that might exist out there wherever they’re hiding, have found themselves in a camp different to the Git standard likely on the basis of electing to be intentionally contrarian / anti-normative as the general catalyst, and rather not, as a function of struggling with Git to the point of being so disillusioned they call it quits and head out looking for greener pastures. I think in practice the most common result of encountering problems with Git is, fix the problems. And functionally I think that’s resulted only in furthering it’s supremacy over alternatives, despite there existing a handful of cultish weirdos who are _really_ into Mercurial and prefer not to fux with Git as a personal lifestyle choice haha)

Giant companies like Google and Meta use alternatives to Git for their internal / closed-source code, because Git couldn't scale to their needs. If I recall correctly, Google transitioned from Perforce to an in-house system, and Meta transitioned from using Mercurial to a custom derivative of it.

Again, no one size fits all...

Are you serious? Anyone who disagrees with you about what VCS is best must be intentionally contrarian?

Haha. That’s a pretty aggressive and surface level read of my comment . For starters it was mostly a joke, and explicitly a conjecture. I was saying, probably most users of a different system do so on for some reason other than, Git being objectively inferior for their purposes (and as others in the thread pointed out, the latter actual is the case at the large scale end of the spectrum for big companies concerned with scaling, not choosing Git).

Secondly, no one has disagreed with me on the matter, as I haven’t put forth a personal opinion, I’m simply impartially making referencing to the fact that Git is the de-facto standard. And from an intellectual perspective, was hoping someone might elucidate more into why that is the case, given my conception is an inferential deduction. at best).

While I’m personally relatively familiar with Git internals, by no means an expert, its the only distributed VCS I’ve ever used and I don’t know anything substantive enough about the alternatives to credibly make a relative value comparison here. They could be the bees knees for all I know, but it seems unlikely given the position Git holds as far as consensus standard choice.

What are the “plenty of examples of things MySQL can do that Postgres can’t”? I honestly can’t think of one, much less “plenty”.

These are just a few random ones off the top of my head!

* Handling several thousand connections per second without needing a proxy or pool (MySQL's connection model is thread/conn vs Postgres using process/conn)

* Handle extremely high volume of primary key range scan queries (MySQL's InnoDB uses a clustered index, see https://news.ycombinator.com/item?id=35909053)

* Handle workloads that lean heavily on UPDATE or DELETE, without major MVCC pain (see https://ottertune.com/blog/the-part-of-postgresql-we-hate-th... for example)

* Semi-synchronous logical replication, for environments which cannot tolerate any data loss during failover; this ensures the statements have reached at least one replica but without the huge latency of synchronous replication

* Use index hints, to ensure random index stats changes don't cause unexpectedly negative query plan adjustments (see discussion in subthread https://news.ycombinator.com/item?id=35909340)

* Handle very high-volume OLTP workloads using direct I/O, since InnoDB's buffer pool design is completely independent of filesystem/OS caching

* Achieve best-in-industry compression by using the MyRocks storage engine (MySQL's pluggable storage engine design has a lot of tradeoffs but it is inherently what makes this even possible)

* Use UNSIGNED int types, to store twice as high max value in the same number of bytes, if you know negative numbers are not going to be present

* Use case-insensitive or accent-insensitive collations out-of-the-box without having to monkey with confusing user-defined CREATE COLLATION

* Ease-of-use commands like SHOW CREATE TABLE

* Silly cosmetic things like the ability to reorder columns in an ALTER TABLE (see https://wiki.postgresql.org/wiki/Alter_column_position)

* A tooling ecosystem which includes multiple battle-tested external online schema change tools, for safely making alterations of any type to tables with billions of rows

Yeah I can’t think of any. I mean if I had to come up with something, I would talk about tooling. MySQL Workbench (when it works) is by far the easiest to use and most feature-rich of all RDBMS.. MS. It runs on any OS too, which is a ding on SQL Server and not Postgres since Postgres’ is a web app- which has the limitations of a web app (no right click for example- which I know is possible in a web app, but last I checked not implemented for pgadmin).