[disclosure: I'm the CTO at NuoDB, one of the NewSQL systems discussed in [4] above]
Totally agree with your comment. While the "NewSQL" category is pretty broad and hard to define cleanly, one common theme is understanding the trade-offs that matter to your applications & operators as you distribute & scale SQL services.
For instance, with NuoDB we've decided that standard ANSI SQL with complete DML/DDL support is a must-have for migrating existing applications. As you distribute the database, the ACID contract you expect with those tools also has to be maintained, and we do that. As others have noted in this thread, however, there are many variants of "consistency." I believe if you're trying to exploit distributed scale, and low-latency through locality of reference, then you're probably willing to trade-off serializability. Using MVCC, logical timestamps (not globally coordinated clocks) and a few other well-understood techniques we provide a scale-out solution that maintains standard levels of isolation and consistency. In practice our customers are traditional enterprises using these capabilities to migrate legacy, high-value systems into modern architectures.
What Google has done is something very few other organizations can do: exploit their massive scale and hardware capabilities to offer something unique. From that perspective, they've also chosen to make trade-offs around syntax, indexing, transaction models etc. There's good commentary from my peer at Cockroach about this already on this thread, but the point is that Google picked a view of the database that makes sense for some applications and not others. Personally, I'm excited that Google has opened up this service and I'm sure it will lead to a lot of good introspection on what we need from modern data management services.
For those who haven't read it yet, I'd highly recommend the Quizlet blog referenced elsewhere on this thread. It's a really good discussion about some trade-offs that Cloud Spanner has made, and why they would or wouldn't map well a given application.
Bottom-line: both Cloud Spanner and NuoDB are examples of the modern, distributed, scale-out systems we're moving towards that focus on consistency, fault-tolerance and modernizing traditional SQL applications.
Totally agree with your comment. While the "NewSQL" category is pretty broad and hard to define cleanly, one common theme is understanding the trade-offs that matter to your applications & operators as you distribute & scale SQL services.
For instance, with NuoDB we've decided that standard ANSI SQL with complete DML/DDL support is a must-have for migrating existing applications. As you distribute the database, the ACID contract you expect with those tools also has to be maintained, and we do that. As others have noted in this thread, however, there are many variants of "consistency." I believe if you're trying to exploit distributed scale, and low-latency through locality of reference, then you're probably willing to trade-off serializability. Using MVCC, logical timestamps (not globally coordinated clocks) and a few other well-understood techniques we provide a scale-out solution that maintains standard levels of isolation and consistency. In practice our customers are traditional enterprises using these capabilities to migrate legacy, high-value systems into modern architectures.
What Google has done is something very few other organizations can do: exploit their massive scale and hardware capabilities to offer something unique. From that perspective, they've also chosen to make trade-offs around syntax, indexing, transaction models etc. There's good commentary from my peer at Cockroach about this already on this thread, but the point is that Google picked a view of the database that makes sense for some applications and not others. Personally, I'm excited that Google has opened up this service and I'm sure it will lead to a lot of good introspection on what we need from modern data management services.
For those who haven't read it yet, I'd highly recommend the Quizlet blog referenced elsewhere on this thread. It's a really good discussion about some trade-offs that Cloud Spanner has made, and why they would or wouldn't map well a given application.
Bottom-line: both Cloud Spanner and NuoDB are examples of the modern, distributed, scale-out systems we're moving towards that focus on consistency, fault-tolerance and modernizing traditional SQL applications.