It may very well be the case that looking at the internals of some database other would provide a different set of lessons.
IMHO, MySQL is especially ugly due to an attempt to insert an abstract interface around its storage engines. IIRC that interface is leaky, and its documentation is pretty spotty. Also, the InnoDB storage engine has a lot of complexity that seemingly duplicates what's provided on the storage-engine-agnostic side of that interface.
One of the big lessons I took away from studying MySQL's internals, and partially confirmed by the "internals" book, was this: Be careful when designing a plugible storage-engines framework for a DBMS; MySQL has some examples of what can go wrong.
That's something you're unlikely to find mentioned in a generic DBMS-implementation book, but is very good to know about regardless.
MySQL can hardly be called representative for good relational databases. That MySQL is underfeatured and performs like shit for any non-trivial query is hardly news.
I'm not going to continue this. MySQL is technically inferior by almost every metric. Businesses don't know what they need, which is why they need something flexible and reliable, not something that will crap out.
I honestly don't know why anything but institutional inertia is even a sane reason to use MySQL. There are better rdbms. There are better key value stores.
You seem to have misinterpreted my objection. There are better books on databases, and MySQL is not necessarily a good example of a database. It tends to do things in its own way. When you get into the sort of situation where the difference between 'how MySQL does things' and 'how things are supposed to work' matters, then typically it's MySQL that's quirky.
Worse is better. MySQL's terribleness is its feature; it means you stop and think before putting business logic in the database, writing a stored procedure, or joining on five tables. While it's a worse database, the /systems/ I've seen built on MySQL are all better than those built on "real" databases.
It really pains me seeing the extent to which people equate what MySQL can do with what RDBMSs in general can do. MySQL's sharding is well known to be an abomination.
I know MySQL has drunk the cool-aid with innodb, but 10 years ago their FAQ entry about why ACID was a bad idea convinced me I didn't ever want to rely on them for anything I might normally rely on a database for. I'm cool with intentionally trading off database features for other features that I value more (like availability), but I want it to be an intentional choice, and then it shouldn't still pretend to be a database for me - admit it's an unreliable data store and just use this unreliable fast thing for a cache, not as a database.
That shows MySQL can be used as a base for building your own key-value store on. It doesn't say anything about it being reasonable (or even good) relational database.
I think both databases have their merits, but the thing that makes me turn up my nose is seeing so many MySql installations done wrong. These are the people who didn't consider things carefully and choose, but just heard that Mysql was faster, installed the default version of that, and now handle people's money with no transactions, and no referential integrity.
So arguably, they are using mysql as a storage engine rather than as a database.
They don't explicitly answer the question "Why didn't you use InnoDB/WiredTiger/etc. for your dataplane?", but you get the idea that they were very happy with the specific characteristics of MySQL for their use case and so they built on top of it. It also sounds like they had some deadlines (specifically, the death of their datastore) that they had to meet :).
As someone who might fairly get scolded for this, we feel like praising MySQL's features is a bit like enjoying the recessed lighting and granite counters in a house whose roof is actively leaking.
There are certainly features MySQL has that Postgres doesn't, but data integrity is problem 1, and most of us got burned by MySQL on that one at some point before we got here. Or, we deployed MySQL and then found out that the features we were depending on were InnoDB-only, but switching to InnoDB cratered our performance. Or we tripped on one too many of MySQL's numerous special cases or silent limitations.
You can use MySQL productively. You can even benefit from its special features. But the thing taken together is a bit of a mine field.
Postgres has some false advertising issues too ("object-relational"?) but the day-to-day living with it is a lot nicer, because the roof doesn't leak. I can live without the granite counters.
From my experience of MySQL's pluggable engines, I learned that this actually complicates things: the user interface ends up being awkward, optimization is harder, adding features is made much harder.
Investigating standalone alternatives therefore seems like a good thing, even for projects starting today.
MySQL is at its roots an SQL-like database specializing in content management. The sorts of data integrity problems that can occur in MySQL are entirely tolerable in a content management environment for the most part. It was designed to be a fast backend for web sites with an SQL interface. A lot of the issues it has are entirely due to that legacy, but those issues don't matter at all when you are using MySQL for content management.
Every single one of those examples are probably using MySQL for some sort of content management.
So it isn't just whether they can tolerate some crap in their systems. It is what sort of crap they can tolerate. If the MySQL gotchas don't result in intolerable crap, then it doesn't matter.
Now, personally I wouldn't run an accounting system on MySQL particularly if I was expecting many apps to access the same db. This is because the sorts of issues that MySQL has are real show-stoppers in these environments. But content management? Why not? Heck many of these data integrity problems may be features in these environments.
For example, suppose MySQL@Twitter truncates your tweets to the maximum length silently without issuing an error. Bug or feature? Suppose it truncates numbers in your accounting software? Those are two completely different cases and while they may in theory be comparable, in practice they are not.
While it's a worse database, the /systems/ I've seen built on MySQL are all better than those built on "real" databases.
This could be a symptom of which businesses choose which databases. Large established businesses are probably going to prefer the commercially supported database, and are probably also going to have the resources to build impressive systems.
IMHO, MySQL is especially ugly due to an attempt to insert an abstract interface around its storage engines. IIRC that interface is leaky, and its documentation is pretty spotty. Also, the InnoDB storage engine has a lot of complexity that seemingly duplicates what's provided on the storage-engine-agnostic side of that interface.
One of the big lessons I took away from studying MySQL's internals, and partially confirmed by the "internals" book, was this: Be careful when designing a plugible storage-engines framework for a DBMS; MySQL has some examples of what can go wrong.
That's something you're unlikely to find mentioned in a generic DBMS-implementation book, but is very good to know about regardless.
reply