I am not sure that NuoDB had Jonathan Swift in mind when it named the 2.1 release of its product “Swifts”. As the major new feature of this version is the introduction of what the Gartner Group calls HTAP (hybrid transaction and analytic processing) and because this is all about operational insight then it is at least apposite.
What is HTAP? In semantic terms it’s an unnecessary acronym (initialism) for what we used to refer to twenty years ago as simply a hybrid database. That is, one that was capable of supporting both transactional and analytic workloads. To be fair, the definition is slightly more nuanced now, in the sense that the analytics are operational analytics rather than the sort of back-end analytics that you might be running in a data warehouse or on a Hadoop cluster. Hence the semantic synthesis between OLTP and OLAP.
This seems to be becoming an increasingly popular positioning—not least because there is a significant demand for running operational analytics against transactional data—and NuoDB is by no means the first database vendor to offer (real-time) analytics against operational data. It may, however, be one of a relatively few that were designed this way from its inception. While the first release of NuoDB was specifically targeted at (distributed) transaction processing it was always intended that it would subsequently support operational analytics. As most of its competitors that offer similar hybrid approaches were originally relational databases—NuoDB is a NewSQL database that uses SQL for access but doesn’t store the data in relational fashion—it is reasonable to assume that they were only designed for transactional processing in the first instance with analytic capabilities tagged on later. This doesn’t mean that they are inferior necessarily, just that NuoDB’s developers had the vision (albeit with late mover advantage) that was invisible to previous generations of developers.
It is worthwhile commenting on the fact that NuoDB is not relational but supports SQL. There are a couple of points. The first is that, strictly speaking, it is a relational database and that the previous statement is false: the whole point about relational architecture is that it is logically relational and that its logical representation is separate and distinct from the storage layer. The fact that relational database vendors went and built a storage layer that is relational (table-based) is neither here nor there: it is the logical representation of data that is important. NuoDB is a relational database.
But the second point is that it need not be a relational database. The company could if it so wished—and the product has been designed this way—be deployed to look like MongoDB or Cassandra or anything else they might like to implement as a logical layer over the underlying physical structure.
Which makes for an interesting conclusion once the company gets around to implementing some different front-ends. It will be a model agnostic database (MAD). Now that’s an acronym worth associating with.