This doesn't match my experience at all. MySQL performance is highly variable, and it's incredibly easy to write simple queries that have truly abysmal performance.
Postgres on the other hand, has always tended towards making things work well (a step that mysql often skips), and then work quickly thereafter.
A lot of MySQL acolytes say Postgres is slow because, unlike MySQL, it doesn't ship with unsafe defaults. MySQL doesn't just allow you to do dumb things, it starts off with many of those settings as the defaults.
To me, the real problem is that people likebarrkel exist. He doesn't know what he's on about, but he likes MySQL. Most of wheat he wrote is flatly false, but he said it confidently. And he's employed someplace that probably uses MySQL.
MySQL got adoption for two reasons:
1) it used to be easier to install; and
2) it has unsafe defaults that mean if an idiot runs a benchmark, it wins.
That's it. That's how it won market. After that, it was network effects, and nothing else. MySQL is a turd. It requires substantial expertise to use MySQL because it is such an awful and dangerous tool. It slows you down as you get better. But most of the people who use it don't know any better, or (like barrkel) they spew nonsense that is the opposite of reality. So it wins.
He doesn't know what he's on about, but he likes MySQL.
You're putting words in my mouth that I didn't say. I don't like MySQL. I prefer PostgreSQL. And I have had a few rough times optimizing some queries in PostgreSQL, whereas I've had fewer such bad times with MySQL, despite using it more often. It's anecdata. Take it for what it's worth.
Time sinks in MySQL have come more from its crappy defaults, from its bizarre error handling (or lack thereof) in bulk imports, and most recently, a regression caused by a null pointer in the warning routine.
If I were working on my own project, I'd probably go with PostgreSQL and figure out the replication story. But I'm not. I do use PostrgeSQL on my personal projects.
(If there was one feature I'd add to PostgreSQL, it would be some means of temporarily and selectively disabling referential integrity. Not deferring it, not removing and readding foreign keys, just disabling. The app I work on does regular 10k-1M+ row bulk inserts, usually into a new table every time (10s of thousands of tables), but sometimes appending to an already 100M+ row table. It would be nice to have referential integrity outside of the bulk inserts, but not pay the cost on bulk insert.)
> Clearly implying that performance doesn't require a careful eye on MySQL
This is highly ironic, since you later say:
> you suck at logic
Funny chap!
(My point was that all the extra features in PostgreSQL give you more solution space, but not all of the solution space is suited to your problem. You have to watch out you're using the specific features in a way that pays off. Whereas MySQL is a bit like a hammer; you need to shape your problem like a nail, otherwise you won't be able to hit it at all. But when you do hit it, it mostly works. It's not a precision instrument though.)
>> makes it easy to do silly things, like turn off referential integrity in a slow query to boost performance.
> Which is really misleading, because it ships with most of that stuff off.
MySQL ships with referential integrity turned on - InnoDB is the default back end. Care to explain more?
(Personally, I wouldn't use MyISAM for my phone book, never mind in production.)
This comment reveals that you're utterly and completely ignorant. If you think InnoDB treats your data with respect by default, you've clearly never actually paid close attention to anything.
As a MySQL DBA, I can tell you that neither MySQL nor Postgres are slow. MySQL has less features than Postgres and that was intentional. MySQL was supposed to be a basic feature set that serves 90%-95% of websites and has easy to set up replication. MySQL has always had more the mentality of light weight and fast.
Postgres is a fine database. It has a lot of features I would like to see in MySQL. However, Postgres is still fighting issues with regular replication while MySQL is now progressing to sync/group-replication.
The features that Postgres already has can be solved in MySQL, but take some work. Sometimes they require me to use temporary tables and pre-calculated summary tables.
MySQL's speed is only variable by the queries that are run against it. MySQL is "simple enough" for developers to write queries for it and in 10%-20% of those cases, those queries could be a bit more optimal or the data model could use some more tweaking. In terms of getting things done, you can do a whole lot before needing someone like me to come along and tweak things.
A performance audit from someone like me every 6-9 months after your company's website has been in use for >3 years can be perfectly fine.
Also the main reason MySQL won out back in the 90s was because they had better documentation and answered questions on their forums faster.
> To me, the real problem is that people likebarrkel exist.
Seriously? you're getting worked up about a database and you conclude that it would be better if certain people didn't exist?
I'd like to remind you that this is HN, not the Linux kernel dev list. For all its flaws, HN still is about civility. You just wished someone out of existence over a database, can you please stop that? Grow up!
I have noticed that comments here are getting abusive. I got replied to with a post full of profanity for making an observation on GNOME, not taking sides on either cases for the argument.
He created that account to "go after" me with a lot of vitriol. It's a bit mysterious though. Why would someone work themselves up into such rage over a database? Normally, you'd explain this as teenage frustration or something. But he's clearly very unhappy, lashing out.
More mystifying than offensive, since it's impossible to take seriously. How can you deal with these people.
It can be quite upsetting though, particularly with the vitriolic posts from complete strangers. If it was from someone I'd known for years I would cope with it better because you can just shrug and agree to disagree, no need for real offensiveness in any situation though.
But from complete strangers who are hammering profanity and abuse into their keyboards as hard as they can, that is quite unnecessary and doesn't make for a nice community. If someone was speaking the things some people on here post to my face, I'd be incredibly offended and they wouldn't be the sort of person you'd want to work with, hang around with or even live next door to. But they don't seem to mind typing it????
These posts rear their head in C++ articles and anything to do with OSX it seems. Really disappointing.
I suppose the best way to deal with it is just detach from it for a while, use another forum, go outside, look at the birds or stroke a cat or something.
There's something very therapeutic about picking up a fluffy cat (I have 4 British Shorthairs, great for fussing) or simply watching sparrows and small birds go about their business in the dust or seed feeders. They continue working without worries, but work hard to survive still and seem happy about it (as far as a bird can be happy). I find it a contrast to us sat in yellow-lit offices with deadlines, stresses, possibly incompetent managers/colleagues and concerns about our existence/paying bills etc.
Speaking as someone who made the switch from MySQL to Postgres... I'm just happy that I can now trust subqueries and schema updates to not blow up my database. And I don't know how I got by without lateral joins and hstore.
I would also say MySQL was adopted by lots of people because for a long time it had a better replication story then Postgres. Easy to setup replication was a pretty killer feature, even if it didn't always quite work as expected.
MySQL also had much cheaper connection setup costs which was a big deal for the CGI and PHP crowds who setup the world at the beginning of every request.
A simpler and faster product won ? I am truly shocked.
And the issues around "safety" stopped being a concern for most developers a decade ago when the ORM was invented. So this idea that you need "substantial expertise" to use it is simply ridiculous.
Postgres on the other hand, has always tended towards making things work well (a step that mysql often skips), and then work quickly thereafter.
A lot of MySQL acolytes say Postgres is slow because, unlike MySQL, it doesn't ship with unsafe defaults. MySQL doesn't just allow you to do dumb things, it starts off with many of those settings as the defaults.
To me, the real problem is that people likebarrkel exist. He doesn't know what he's on about, but he likes MySQL. Most of wheat he wrote is flatly false, but he said it confidently. And he's employed someplace that probably uses MySQL.
MySQL got adoption for two reasons:
1) it used to be easier to install; and
2) it has unsafe defaults that mean if an idiot runs a benchmark, it wins.
That's it. That's how it won market. After that, it was network effects, and nothing else. MySQL is a turd. It requires substantial expertise to use MySQL because it is such an awful and dangerous tool. It slows you down as you get better. But most of the people who use it don't know any better, or (like barrkel) they spew nonsense that is the opposite of reality. So it wins.
Network effects suck.