The system recognizes that two concurrent transactions are trying to update the same record. If the first commits, the second will return an update conflict. The application can then restart the transaction.
These are the same MVCC semantics I used in Rdb/ELN (1984), Interbase (1986), Firebird (1999), and MySQL Falcon (2006). The implementation, however, is wildly different.
The C in ACID is consistent, not serializable (i.e. it's not ASID). Consistency means that declared consistency constraints are enforce -- no dirty writes, no violations of unique indexes, referential integrity, and anything else that the bells and whistles supports.
Let me give a simpler example: Database with one table of one field, a number. One transaction: count the number of records and store that number.
A serializable system will force one zero, one one, one two, etc. But a consistent system can have two zeros and no ones. Why? Because that's what each concurrent transaction saw? Nothing wrong with that. But if application semantics dictate that each value must be distinct, then put a unique index on the number and the system will enforce uniqueness. Automatically enforcing "auto-magic" constraints that nobody cares about is why serializability destroys scalability of distributed system.
In NuoDB all messaging is asynchronous and batched, making it very fast and efficient.
NuoDB doesn't have a centralized transaction controller. It doesn't have a centralized anything. And it isn't "like" anything else -- all new. It's a distributed database without distributed transactions.
In a nutshell, it isn't based on pages or disks but distributed objects. Each distributed object, called an atom, can exist in as many places as necessary. Each atom instance knows of the other instances and replicates changes. Transaction nodes do SQL and are diskless. Archive nodes listen to replication and store serialized atoms on disk, S3, or some other KV store. If a transaction node needs an atom, it gets it from another transaction node or, at last resort, from an archive node that fetches the atom from disk, S3, or wherever.
The question really isn't SQL but ACID transactions. If you can do ACID transaction, SQL drastically reduces the amount of data transmitted.
There is no intrinsic reason that ACID transactions, with or without SQL, can't scale, just that up until now, it hasn't.
And there's a reason that until now, it hasn't. From the beginning of time, academic computer "scientists" have confused the terms serializability and consistency. In short, serializability is a sufficient condition for consistency, but it isn't a necessary condition. If you design a system that enforces consistency without requiring serializability, it scales. Period. Legacy RDMSes don't work that way, but that's their problem.
These are the same MVCC semantics I used in Rdb/ELN (1984), Interbase (1986), Firebird (1999), and MySQL Falcon (2006). The implementation, however, is wildly different.