Enterprise Open Source Magazine reported that MySQL is now capable of managing a 4GB database! But that is not all, it seems the deployment mentioned in the article can even scale to 14GB! Regarding MySQL, the article states:
“We provide customers with fault-tolerant availability of 99.999 percent”, says Mike Wiedemann, MySQL AB’s country sales director for Central Europe. He also explains the details of the Toto-Lotto’s MySQL Cluster implementation: The software is run within a traditional architecture on the presentation, application and persistence level on two SQL and four NDB nodes in a Linux environment. Although the database currently holds 4 GB, the system is designed to comfortably scale to 14 GB and 1.600 queries per second.
And:
According to Lotto Niedersachsen, their main reasons for the future expansion of its MySQL use are: High speed, Easy scalability, Availability of high-quality professional support, Excellent price/performance ratio.
It is not clear whether this MySQL deployment is back-ended with InnoDB or not. If not, I wonder if that had anything to do with the fact that Oracle owns InnoDB now? No matter the reason, I think either the bar is set pretty low for MySQL, or the article reported the database size one or more orders of magnitude incorrectly!
Kevin Closson's Blog: Platforms, Databases and Storage 
Hi Kevin,
doesn’t a MySQL Cluster have it’s own storage engine? I think I have read/heard it some while ago. Anyway, MySQL Cluster seems to be an extra product which you just get with a service contract.
Patrick
——————————-
http://inside-apex.blogspot.com
Stop it. Or I will tell Sheeri.
Must be a typo, as it appears (from the docs) that it should be able to handle terabytes:
http://dev.mysql.com/doc/refman/5.1/en/storage-engine-choosing.html
NDB stores data in RAM. To scale to 14 GB they would need 28GB of RAM spread across the 4 NDB nodes.
Good follow-ups folks, thanks. I must admit that I did a little speed-reading to start with and didn’t key in on the fact that this is an NDB deployment…I let my joker trigger before my thinker.
I still don’t think 4 or 14GB is any interesting size, and since NDB is an in-memory database, I should think 1,600 transations per second wouldn’t be interesting either…but then who knows what a “transaction” is in this context…oh well…
“doesn’t a MySQL Cluster have it’s own storage engine”
Storage engine for MySQL cluster? Well, it’s share nothing clustering based on replication technology. Why would you need storage engine for that?
Hehe… there is a “storage” engine for MySQL cluster. It stores the data in memory periodically flushing it to disk. It’s not like Oracle with buffer cache – it’s pretty much like the WHOLE database must be in memory. Here is where 4 GB and similar figures are coming from.
It looks like re-invented raid 1+0 on table row level whereas rows are spread into different “data nodes” based on a hash function on primary key and replicated (read mirrored on several nodes).
Darn expensive mirroring. People are complaining that RAID 1+0 is too expensive as it requires more disks compare to RAID 5.
If that’s too expensive for you – switch to MySQL cheap solution – mirroring in memory.
Anyway, it seems I can go on and on now that I got an excellent MySQL cluster overview during Pythian Goodies. It should be available as YouTube video on our blog at some point.