NuoDB release 2.0

NuoDB has just released the second version of its eponymous NewSQL database with extended geographical support and the introduction of a server-side programming model.

NewSQL databases fall into two categories. What they all have in common is that they are SQL-based, ACID compliant, transaction-oriented databases that have a much smaller footprint than traditional relational databases used for transaction processing, run on lower cost (commodity) hardware and they tend to outperform their erstwhile relational peers. The reason for this is that they don’t have (and don’t need to have) all the bits and pieces that have been acquired over twenty or thirty years of development and which, while seen as essential at the time they were incorporated into their respective products, are now out-of-date and pretty much useless, but which are still required in order to support backwards compatibility with older version of those products.

What differentiates the two classes of NewSQL products is whether they actually have relational engines underneath the covers. In the case of NuoDB it does not. Under the covers – where you don’t see it because you access it through SQL – NuoDB actually uses either a flat file or a key value store (such as HDFS) with append-only storage and versioning (with multi-version concurrency control). However, that’s only a bit of the story when it comes to NuoDB.

The really important part of the NuoDB story is that it is a distributed database in a way that is unlike any other database I have looked at. The key to this is that storage is separated from processing. Nothing new in that. But in NuoDB, as opposed to a shared disk system or a shared nothing system or even a system with replication, you have a complete copy of the database in every location (in the storage layer) and processing done entirely in-memory in the transactional layer, where transaction servers are distributed in much the same way as storage servers. This distribution is peer-to-peer, so there are no bottlenecks associated with master nodes, and you can have as many transaction servers and as many storage servers as you like and there does not have to be any particular relationship between the two.

Furthermore, NuoDB supports continuous availability. This means that you can add or remove both transaction and storage servers at will. This is very important in a distributed environment: the whole idea is that in a web-facing environment, say, you can have servers supporting the Far East active when the Far East is busy and you can have servers supporting Europe active when Europe is awake, but you don’t need all of them to be running all of the time. You can add transaction servers whenever you want to but with storage servers they have to update themselves with the current status of the database – which they do automatically – before they are ready to support processing.

I like NuoDB: it seems to have cracked a problem – geographical distribution – that has not been really successfully addressed hitherto. However, that doesn’t mean the product is perfect. For example, in this sort of environment I’d like to see the use of (reverse) deltas rather than writing a new copy of the data every time. On the other hand, the product, despite a lengthy beta cycle, is still pretty new (first release was in January this year) so you can’t expect everything.

I expect NuoDB to continue to gain traction in geographically dispersed web-facing transaction-oriented environments – because that’s where it has particular differentiators. What I will be interested to see is how successful the company is at spreading its message and product into other use cases. There is a potential danger that the product gets labelled as a one-trick pony and a niche product, whereas it has the potential to be used in a much broader range of transaction processing environments.