I don't think the definition of real database is size of system or number of deployments. MySQL proves that most systems are application-centric rather than database-centric. There are operational issues that need to be taken into account when deploying any database system and one can argue both sides of the "real or not real" on MySQL. The issue isn't whether or not MySQL is a real database but, rather, what tools are appropriate for which deployments. MySQL and the other open-source databases are proving that customers recognize that the database-centric premium that Oracle charges is no longer justified.

MySQL is not ACID compliant. PostgreSQL is. Once you understand what this means, you do not want to use MySQL.

The history of computing with respect to managing data is littered with ideas that ranged from overly specialized to fundamentally flawed; I'm sure that everyone in the industry can think of at least one example on either end of the spectrum. Given that, rapid adoption of a particular idea or application over a period of a few years doesn't mean that it's sound or appropriate for the tasks for which its being used. I think MySQL fits into this scenario, "hyped" even, as it was sandwiched between 3 good to great technologies, GNU/Linux and Apache being great, and PHP being good.

I've encountered numerous scenarios in the last few years where the limitations of MySQL have caused hard stops in applications *written for MySQL* that had scaled to a level of volume or activity that causing MySQL to either perform poorly (partioned tables) or fail completely (corrupted, not recoverable data).

If you value your data and expect to be able to scale the management of that data without building a complex architecture around it, just to provide layers of protection for what the data management application should be doing for itself, then you need to use something that has transactions (not just for certain engines or table storage structures) and something with integrity for the backup of those transactions, as well as the ability to tune that system per processing scenarios that may fluctuate throughout a processing period.

The list of things that MySQL doesn't do well, as well as the list of features that it claims to support that are both extremely new and have been known to fail, should cause, and has caused, someone that values their data to consider using a "real" DBMS, such as PostgreSQL, or even better, Ingres.