As NoSQL databases mature and adoption widens, some in the NoSQL sector believe users will trade ease of use for reliability. At Orchestrate, we believe this is a false choice.

The following excerpts are from JAX’s interview with Bob Wiederhold, CEO of Couchbase, on their strategy to compete with MongoDB.

JAX: How have NoSQL market dynamics changed since Couchbase first launched?

Wiederhold: In the first few years of the NoSQL market, it was really characterized by grassroots developer adoption. Developers were downloading the software, playing around with it, and generally using it on relatively small applications and somewhat rarely using it for business critical applications. That really started to change in a big way in late 2012 and throughout 2013. What we started to see in a big way was big internet companies and enterprises starting to believe that NoSQL was really strategic to their infrastructure and they started doing deep technical evaluations of the various competitors and then they began to deploy NoSQL in a big way under business critical applications.

Before Orchestrate, a number of us worked at Basho, which built a database called Riak. Riak came into the NoSQL scene in August of 2009. We’d even been told the year before by investors that “databases are a solved problem” and that no one would seriously consider databases other than Oracle and Microsoft and then proceeded to beat Oracle out on a number of huge projects. We watched the NoSQL market evolve. Based on this experience, I agree with Wiederhold on the history.

Wiederhold then goes on to discuss the evolution of the NoSQL market to its current status:

We started to see a very significant increase in this period, when the dynamics of the market really started to change. It that phase, it was a much heavier focus on ease of development, and Mongo was quite strong as a result during that first phase, and gained some significant popularity. What we’re seeing in this second phase, with the more business critical and mission critical applications, is that scalability and performance are dramatically more important because these apps are already operating at significant scale and they need higher performance.

Our own experiences during this period with Riak (known to be horizontally scalable, resilient to failure, and not particularly simple to run) supports Wiederhold’s description of the evolving NoSQL. MongoDB is incredibly easy to get started. Most package managers have a one liner to install MongoDB and the UX of Mongo has always been top-notch. MongoDB’s makers succeeded in optimizing it for “ease of development.” Unfortunately, central to Wiederhold’s assertion that “second phase” use cases have been willing to sacrifice ease of use for scalability and reliability is the notion that such a choice is unavoidable, that one must either choose ease of use or the scalability, and that business critical applications make this choice always in favor of the latter properties.

For the Orchestrate founders, we all felt the shift into this second phase as well, but we didn’t believe such a choice was necessary. In fact, we felt the opposite – that the second phase of scalability and performance, in order to succeed, had to maintain and master the lessons from the first phase on ease of development.

Two trends shaped our belief:

First came the rise of polyglot persistence. As we moved into the “second phase,” developers and operations teams had many new databases with which to build applications. Under pressure to add search, geo, social, and event functionality to their applications, developers could now play to the strengths and overcome the limitations of each database. Unfortunately, polyglot persistence meant operational complexity. Companies ran multiple databases in production. The move from the first to the second phase came with a lot of additional costs.

Second and perhaps more importantly, we saw the rapid rise of cloud computing. Suddenly spinning up new server instances became easy and inexpensive. What we found important here was that expectations were changing. The developer no longer needed to tolerate long delays and high costs to use basic infrastructure. If basic services could be accessed and scale horizontally to vast numbers just by programming an API, why would developers both running their own corresponding versions.

So, we saw developers wanting access to more query types and we saw API-driven services replace traditional infrastructure.

Given those two trends, it seems silly to me to believe developers will resign themselves to the “second phase” of NoSQL software where they trade ease of development for scalability and performance, and it’s operational complexity. Scalability and performance should not get in the way of developers innovating, any more than spinning up a server or environment does (AWS, Heroku, etc).

We believe the individual developer is critical for creation, innovation, and evolution. It is the “grassroots developers” that build businesses that explode. When those businesses grow, developers shouldn’t have to trade “ease of development” for “scalability and performance”.

We believe in the future what was once heavy infrastructure will take seconds to sign up for and begin using. When users are asked to choose between scalable, high performance systems, or easy-to-use data infrastructure, they will choose a third option – one that combines both options.