Matt Aslett from the 451 group created a term called “NewSQL”. On the definition of NewSQL, Aslett writes:
“NewSQL” is our shorthand for the various new scalable/high performance SQL database vendors. We have previously referred to these products as ‘ScalableSQL’ to differentiate them from the incumbent relational database products. Since this implies horizontal scalability, which is not necessarily a feature of all the products, we adopted the term ‘NewSQL’ in the new report.
And to clarify, like NoSQL, NewSQL is not to be taken too literally: the new thing about the NewSQL vendors is the vendor, not the SQL.
As with NoSQL, under the NewSQL umbrella you can see various providers, with various solutions.
I think these can be divided into several sub-types:
- New MySQL storage engines. These give MySQL users the same programming interface, but scale very well. You can Xeround or Akiban in this field. The good part is that you still use MySQL, but on the downside it’s not supporting other databases (at least not easily) and even MySQL users need to migrate their data to these new databases.
- New databases. These completely new solutions can support your scalability requirements. Of course, some (hopefully minor) changes to the code will be required, and data migration is still needed. Some examples are VoltDB and NimbusDB.
- Transparent Sharding. ScaleBase, which offers such a solution, lets you get the scalability you need from the database, but instead of rewriting the database, you can use your existing one. This allows you to reuse your existing skill set and eco-system, and you don’t need to rewrite your code or perform any data migration – everything is simple and quick. Other solutions in the field are dbShards for instance.
As in NoSQL, I believe each NewSQL solution has its own spot, answering specific needs.