NuoDB set to improve distributed SQL performance

Multiple types of databases are available today, each intended to solve a different need.

For scalability and cloud-native capabilities, distributed SQL databases such as NuoDB are an increasingly popular option. The vendor, based in Cambridge, Mass., released version 4.0 of its namesake distributed SQL database in July 2019 and is planning to release version 4.1 early this year, adding new performance and cloud-native features.

Ariff Kassam

In this Q&A, Ariff Kassam, CTO of NuoDB, provides insight into the modern database landscape, why cloud native matters and where his company is headed with its next release.

How has the database market changed over the last few years?

Ariff Kassam: In the early days of NuoDB we were fighting the NoSQL movement. We have a distributed SQL database, but back then, people assumed that NoSQL was the panacea, the silver bullet that would solve everything.

Now people realize that there is still a need for SQL, ACID [atomicity, consistency, isolation and durability] and strict consistency. People now also want distributed environments.

Over the last three years, the market has exploded in terms of options for distributed SQL capabilities. And quite honestly, it has been good for us, because you don't want to be in a market of one.

Where do you see the intersection of databases and Kubernetes cloud-native infrastructure?

Kassam: The future of Kubernetes is stateful applications. That's where enterprises need to go. They've all been playing with stateless applications, but they see the value and the opportunity to manage the entire workload in an orchestrated environment like Kubernetes with operators and it reduces the cost of ownership significantly.

At NuoDB we haven't changed anything significantly in order to be cloud-native, because of how we separate compute and storage and how we create database services. All we really did was put those services in individual containers and then orchestrated the connectivity between those containers. We made a couple changes at the management layer to be able to deploy new containers or have other containers join. But fundamentally, the architecture hasn't changed.

NuoDB has a free community edition, but it's not open source. Does being open source matter for a database?

Kassam: Whether the database is open source or not doesn't really matter to the end user. Databases can have different pricing models and costs of ownership. At the end of the day, the database has to do what the database needs to do, whether it's open source or not.

At the end of the day, the database has to do what the database needs to do whether it's open source or not.

We don't see a lot of companies saying that NuoDB needs to be open source so they can contribute or so they can get access to the code. They just need to ensure that that system is adopted by a community of users and they need validation that this is not just a fly-by-night type of system.

Customers have asked us if we are going open source and we might. There's nothing set in stone that says we will or we won't. But it shouldn't really matter to a customer.

Given the complexity in the database market, how should customers figure out what's the best option is for them?

At a very high level, you start with the type of workload -- is it an analytical workload, an operational workload or some sort of specialized graph type of workload?

Let's say you are focused on the operational side, then you need to need to think through the next level details which include considering a relational model or non-relational model. If you need strict consistency then you go down the relational side.

Once you're on the relational side, you start thinking about if you are coming from an existing application and if there is an existing application running on Oracle, SQL Server or PostgreSQL. If you're coming from an existing application, can you live with the boundaries of what I refer to as a single master or single leader node? Or is there a need for better availability, or are you looking to scale out? If you hit performance limitations on scaling then there could be a need for a new architecture like distributed SQL.

With distributed SQL architecture, that's where you get CockroachDB, YugaByte, us [NuoDB] and others.

What's next for NuoDB?

Kassam: So we're doing a 4.1 release likely for the end of January. We're doing a lot around Kubernetes and will have operators in the Google, AWS and OpenShift marketplaces. With the operator, you can deploy to any one of those Kubernetes clouds, so that's a big thing.

Performance is always a big thing. So one of the things we're focused on in this release, from a performance standpoint is our online index creation capability. A big advantage for NuoDB and why customers choose us is that there are no outages, even for maintenance. So for maintenance, online index creation has to be online and we do that today, but we could do better on performance. So we're working on reducing the time it takes to create the index.

We don't have a DBaaS [database as a service] now, but that's something we want to get to. We're probably looking at the later part of 2020 for something like that.