I just RTFA, from what I can tell this affects anyone who needs to run untrusted code in a JVM with a SecurityManager, not just applets.

That said, I can't think of any reason to do that besides applets, so most vulnerable users are those with browser plugins. Virtually everyone I know who runs Java deploys it within a servlet container where untrusted code is not normally a concern. Given that, the story seems a bit overblown.

As another poster pointed out, this is a false dichotomy. We're emerging from a technology monoculture of "every DBMS must be SQL" to "it's possible, even viable to design, implement and use a DBMS that does not implement SQL". Anyone advocating a mass exodus from SQL-land is a fool. Props to the NoSQL guys for opening our eyes to fresh ideas.

There's no need to stick with any single DBMS platform for 100% of your organization, unless you're so small that you have but one server total, and then I suspect this debate is largely irrelevant to you anyhow.

We're not Google, but we have some of the same problems Google faced with scaling up our applications for the Internet. We do use MySQL, having some 35+ instances of it. Our application processes in excess of 1000 transactions each second, and we know it'll be difficult to scale to tens of thousands of transactions per second without some fundamental changes. Today we survive by imposing limitations on developers writing OLTP applications--things like "all row operations must search by primary key" and "no table scans, ad-hoc queries or file sorts". The access language is still SQL, but increasingly we don't *need* SQL for OLTP transactions. We could plug in something today that is equivalent and far simpler.

What we're lacking in SQL-land is a good way to host DBMS applications on distributed infrastructure, e.g. in the cloud. There are clustered databases available, but these often require fast/short interconnects, may have difficulty scaling above bandwidth limits on a local network or SAN, and can be frustratingly fragile to use in the "real world". Not to mention expensive. This is due to the consistency model imposed on such systems, i.e. the "AC" in ACID.

Data sharding is a popular way to exceed the limits of SQL, but once you introduce sharding you're treading on "NoSQL" waters already. You can't retrofit sharding onto an application that isn't aware of it, not very successfully, in my experience. So developers need to become acutely aware of the storage tier and design for it, meaning they've already lost the perfect abstraction of SQL.

I'm keenly interested in emerging products like the Cassandra database, and while I have no intent of ever abandoning SQL (and probably even MySQL) in our organization, we're absolutely going to take "NoSQL" for a spin to see what it delivers in terms of cost, complexity, relability and performance.

The NDB releases basically forked from mainline MySQL. Latest is NDB 7.x, which is actually very good at what it does. Not *quite* ready for what we need but getting very close. ALTER ONLINE is a nifty feature... I've used it to add/drop indexes on the fly from tables in continuous use.

Earlier releases of NDB required that all indexes and data fit in main memory, but that has been remedied with disk data tables. Currently, disk data tables can only store fixed-length data (all strings are padded to their full length). Once that limitation is addressed, I'll be ready to look at it again.

If you applications need frequent table scans, forget about NDBCLUSTER. If however you meticulously access all your data by primary key, I find NDB scales just fine with workload.

Okay I'll bite. I'm not familiar with postgresql versions since about 7.x.

From http://www.postgresql.org/about/:

• An enterprise class database, PostgreSQL boasts sophisticated features such as Multi-Version Concurrency Control (MVCC), point in time recovery, tablespaces, asynchronous replication, nested transactions (savepoints), online/hot backups, a sophisticated query planner/optimizer, and write ahead logging for fault tolerance. It supports international character sets, multibyte character encodings, Unicode, and it is locale-aware for sorting, case-sensitivity, and formatting. It is highly scalable both in the sheer quantity of data it can manage and in the number of concurrent users it can accommodate. There are active PostgreSQL systems in production environments that manage in excess of 4 terabytes of data. Some general PostgreSQL limits are included in the table below.

Which of these are not also true of mysql? The InnoDB storage engine also has MVCC, snapshot recovery, hot backups, etc.

What are the compelling differences?

Everytime I see this debate on slashdot it invariably degenerates into claims of mysterious missing features (what are they?) or non-transactional characteristics of MyISAM. Too bad, because I'm genuinely interested in a good comparison. I use MySQL extensively today but have worked on both in the past.

Anyone still tempted to go with the "non-acid" argument... give it up, else risk looking ignorant or foolish. MySQL is designed to support many storage engines. Anyone using MySQL this past decade who cares about their data creates most of their tables as InnoDB tables. And InnoDB is a very very good storage engine, if it matters.

I may have to try postgresql myself, if only to get to the bottom of this. What doesn't it have that I sorely need? Perhaps nothing. Then again mysql isn't missing much, either, for our needs. Perhaps, in the end, this is more like comparing AMD to Intel--no clear winner.