I'm very familiar with the TPC-C spec and the problem can't be brushed off with "concurrency!". There are multi-second waits in a large percentage of transactio

I'm very familiar with the TPC-C spec and the problem can't be brushed off with "concurrency!". There are multi-second waits in a large percentage of transactions. Nobody does this in any performant OLTP system today, but sure, concurrency! Except the benchmark limits how many of these transactions can be concurrently operating on a warehouse, one of its core models. So the only way to scale throughput is to add warehouses. You end up simulating a company with a million warehouses, each with a fairly small load. Furthermore, to run a million transactions a second, you'll need several million open transactions. That's why you see armies of client nodes in the spec of the systems on the leaderboards. The append-only data model is also difficult. If you removed waits and allowed old data to be pruned, the benchmark would be much more useful. So yes, technically Oracle Exadata OLTP Clustering has multiple CPUs connected by an high speed interconnect. Cluster. My dual socket commodity Dell server also has multiple CPUs connected by a high speed interconnect. Cluster? My point was not to argue about a word, just that Exadata is not what some typically think of as a cluster in modern distributed systems. They've moved some smart filtering into a SAN and plugged that into RAC and shipped it all in a big hot tower-thingy. It's not bad in any way, it's just closer to SMP than other kinds of network-based parallelism.