That's a heckuva deep cut.
I wonder why/how MySQL got so popular, when in my head the go-to is Postgres (perhaps because I worked on Django/Rails stuff early on). Is it because of Oracle and their marketing/sales work?
That's a heckuva deep cut.
I wonder why/how MySQL got so popular, when in my head the go-to is Postgres (perhaps because I worked on Django/Rails stuff early on). Is it because of Oracle and their marketing/sales work?
MySQL's popularity long predates the Oracle acquisition. MySQL got popular because it was usually available (alongside PHP) on shared hosting and had very fast read performances (using the default MyISAM storage, at the cost of write performances or actually caring about your data). What with the web being front-loaded on read, that made it a pretty good fit.
Meanwhile historically postgres was byzantine to set up and slow. It cared much more for your data and had plenty of features (custom types! procedural languages! transactional DDL!), but it didn't really work OOTB (still doesn't, IIRC the base configuration still assumes rotating rust and 128MB RAM or some shit) and wasn't available on most hosting platforms, especially not the really cheap shared hosts.
Also while Django defaulted to postgres, I'm pretty sure Rails used to kinda-sorta default to mysql (I'm talking 10 years back, many plugins/extensions didn't work properly on pg).
https://www.percona.com/blog/2016/05/03/best-practices-for-c...
It's because the two projects had different starting goals, and thus attracted different audiences. MySQL was designed to be small and fast, while sacrificing consistency and integrity. Postgres was intended as an enterprise class DB from day one, with the expected robustness, integrity, and feature set. It led MySQL on features for many years, but lagged on speed.
During the .COM boom of the 90's, the flurry of startups cared more about speed and ease-of-use, and were willing to sacrifice consistency. Thus it became the default choice for most open-source projects and web development. Because of this, a whole ecosystem of support and tooling developed around MySQL, which reinforced the industry trend.
As to performance, Postgres has long since bridged that gap. As to ease of setup/config - Postgres was never difficult in the first place. The perceived complexity was due to its more robust feature set and security model. There was certainly more to learn, but honestly, it was never so terribly difficult as some people then and now seem to view it.
It provided fast relational SQL database for the early web application stack without any concern of maintaining ACID (Atomicity, Consistency, Isolation, Durability) that "real" databases like Postgres providied. It had slight speed advantage and that was enough to turn the scale against Postgres.
MySQL was demonstration of Worse Is Better in the database world. https://www.dreamsongs.com/WorseIsBetter.html
Yep, over and over again, "worse is better" proves itself as the all-important software mantra. Get that flimsy "database" out the door and loop back around to fix the "eats data" bugs 5+ years later.
The key to adoption seems to be to pinpoint something that people really want ("super fast 'SQL database' that I can run virtually for free" c. 1999), rush out a one-fifth-working version of the headliner features and pretend like it's all well and good, and then work to spread that solution as widely as possible.
Once you get the momentum, it's impossible to stop, and someone like Sun swings by to ask if you'd mind taking a billion dollars off their hands.
I don't think there's really a credible argument that technical merit has anything to do with success or adoption anymore (beyond just "superficially appears to work"). MySQL is a good specimen, but JavaScript is the real poster boy for the indisputable triumph of "worse is better".
Not sure it beats PHP in being worse. But at least both got substantially better with recent versions.
The MS-DOS of databases
Eventually Postgres got fast enough and MySQL got reliable enough, which has made the distinction between them somewhat fuzzier today. But by then MySQL had become the standard database offered by umpty zillion web hosts, and ubiquity is a hard position to dislodge someone from.
MySQL still doesn't support nested DDL's, and this has caused me extreme amounts of pain in old projects where consistency was expected and we did not receive it on crucial payment processing.
My experience recently and historically has been the exact opposite. Postgres seems to blow up in more mysterious and hair-yankingly frustrating ways than MySQL does. "Why Uber Engineering moved from Postgres to MySQL" echos a lot of the issues I've had with Postgres in large production environments.
this is very scary, if not fatally scary.
Things might have changed now for Postgres.
This, plus strong consistency to prevent shooting yourself in the foot, is valuable for 99% of use cases where you don't need insane web scale.
Edit: Added more context
MySQL was the M in the LAMP stack, and was installed on many linux distros by default.