In an interview with Colin Barker last month, Eliot Horowitz, MongoDB's CTO, said his goal in creating the platform was to make it the database that just gets out of developers' ways. Not surprisingly, MongoDB's original claim to fame was that it was very developer-friendly, just like its open source ancestor MySQL was as part of the LAMP stack.

We had a chance to reprise Barker's session with a follow-up discussion at MongoDB's New York offices just before the holidays. First, we looked back. Over the past year, MongoDB's developer focus took it into adding multi-document ACID transaction support, growing its Atlas managed cloud service, and adding a serverless platform called Stitch.

There's much to protect. In its first year as a public company, the company has regularly beaten the street, with share prices more than doubling and revenues growing 50% year over year since the IPO. However, as the company is still in growth mode, the balance sheet is still in the red. But averaged out in earnings per share, the losses have been less than what Wall Street was predicting. MongoDB has not had the same bumpy ride as Cloudera or Hortonworks.

An example of MongoDB's growth strategy is its October announcement for acquiring mLab, which is intended to grow the company's cloud footprint with a provider that claims over 1 million deployments (when free community edition installs are included). The $68 million deal closed Nov. 1, 2018.

Maybe the focus should be on the mundane. In the Q3 investor call, MongoDB CEO Dev Ittycheria pointed to customer wins, not with the digital online usual suspects, but what he termed "conservative" industries, such as the UK tax authority and the Maryland Health Exchange. Go ahead, bore us.

Even if the installed base looks more mainstream, the core technology is still relatively early in the maturity curve; capabilities, such as ACID transaction support, that are taken for granted in the relational database world, are still emerging in the NoSQL landscape that MongoDB is part of. The choices are anything but flavors of vanilla.

For transactions, MongoDB adheres to what it characterizes as a more traditional approach emphasizing strong consistency; others, such as DynamoDB and Cosmos DB, provide choices on the levels of consistency from eventual to strong. MongoDB also allows more complex transactions that involve multiple operations; while it does not have a firm limit on the number of operations in a transaction, it advises developers to keep the number under 1000; by contrast, with DynamoDB, there is a limit of 10 operations. This places the onus on the developer to decide how much complexity to tolerate in a transaction.

Given that NoSQL is an umbrella for a wide variety of databases that support a variety of database types, the choice – and design assumptions – of competing platforms are quite varied. For instance, MongoDB is designed around the document model; others, such as DynamoDB or Couchbase, began life as key-value stores and evolved with support of document models. You have single-purpose databases, like Amazon Neptune, Neo4J, or TigerGraph, that are strictly graph databases. And then at the far end of the spectrum, Cosmos DB is promoted as a multi-model database, where the data model is driven by the API, for which document, relational, graph are among the choices. By contrast, while MongoDB is a document-centric database, you can use a lookup operator to expose the data as a graph.

MongoDB, like most of its NoSQL counterparts, began life as an operational database. But with growing demand for real-time intelligence, operational databases are adding richer querying capabilities. MongoDB's journey to analytics began with the aggregation framework followed by the BI connector, and capped most recently with a beta on MongoDB Charts. Cassandra and Couchbase have also done so, but with the different approach of SQL-like query languages. MongoDB Charts stands out, not because it is a Tableau replacement (it's not), but because it provides a direct path to visualizing JSON document data without having to flatten it to relational form. It does so with a rules-driven approach that guides the developer on what axes to visualize.

While MongoDB and Amazon compete with operational databases, their relationship is more classic frenemy, as AWS is one of the public clouds that MongoDB's Atlas managed service supports (Atlas runs on all three major public clouds). And at the recent AWS re:Invent, MongoDB announced several new features to further embed its service in the Amazon cloud: a new JavaScript SDK for its Stitch serverless cloud managed service, supporting interaction with AWS services, such as Kinesis for receiving or generating streams, or QuickSight for analytics. A related capability includes triggers for event-driven apps, embedding code inside MongoDB for triggering external services such as Kinesis. And it has added support for customers to connect to Atlas on AWS with their private networks across multiple AWS regions.

With its origins as a developer-friendly database initially targeted at web applications, it was logical for MongoDB to extend its Stitch serverless platform to mobile. Among recent releases has been a new compact footprint MongoDB Mobile database designed for intermittently-connected scenarios with periodic synchronization with the back end database. It's a segment where MongoDB faces competition primarily from niche providers – not the cloud giants, at least for now. But as each of the cloud providers are bursting to supporting edge devices for IoT, we wouldn't be surprised if mobile were next on their lists. Although in general release, the MongoDB Mobile is a work in progress as the sync feature is currently supported on Android, with a version for iOS coming soon.

As we noted in our look ahead last week, the cloud is providing the path for distributed databases to emerge from the theoretical. Admittedly, MongoDB was distributed with its support for sharding before it ever added a cloud service. For the cloud, MongoDB has added global clusters, primarily as a solution for customers facing data sovereignty issues or providing cross-region disaster recovery. A use case could involve global banks facing local laws stipulating that data from local customers stay inside the country of origin.

MongoDB is hardly alone in addressing globalized databases – each of the major cloud providers have over the past couple years begun introducing globally distributed editions to their relational and non-relational databases. Like ACID transactions, this is also an area that is becoming another checkbox, but where there is no de facto standard design. For instance, DynamoDB recently introduced global tables, using multi-master capability for supporting local reads and writes in globally distributed databases.

Looming over all this is the growth of cloud adoption. At Ovum, we have predicted that in 2019, half of all new Big Data workloads will be deployed and developed in the cloud. Over the past year, MongoDB Atlas has grown 300%, now accounting for over 20% of MongoDB's business. The mLab acquisition reflected the urgency of accelerating growth in this space; mLab introduces a self-service model that could help grow the footprint.

And so was the introduction of new licensing. As an open source database, there is already an ecosystem of MongoDB managed cloud providers, a few of them including ScaleGrid and Alibaba Cloud, which offer managed MongoDB services, and others such as Percona and Bitnami that provide MongoDB support in their clouds.

MongoDB wants to avoid the fate of Redis, which has stirred up significant backlash with its new Commons Clause license. Both are leery of having the cloud giants cannibalize their business without putting skin in the game – other contributing back to the project or paying for commercial licenses. That's where SSPL comes in: third parties can still offer MongoDB services, but they must open source any related management tooling. While the tooling must be open source, it doesn't have to be under MongoDB's open source project. MongoDB has submitted its SSPL license to the Open Source Initiative for feedback.

Avoiding becoming a victim of its own success will be part of the script for 2019, as there is still plenty of white space for MongoDB to attack.

We believe that in 2019, MongoDB will have two priorities. First, keep following its customers into the cloud through a path that differentiates itself from AWS, Azure, and GCP native platforms: cloud independence. The first step is already done: Atlas already on AWS, Azure, and GCP. The next step, making its platform even more cloud-native by thoroughly embracing Kubernetes, is in the works.

The other task facing MongoDB reiterates a theme mentioned above: become more boring. As MongoDB courts a mainstream base beyond its digital online roots, it needs to adopt the security, database automation, and manageability that Oracle customers already take for granted. It won't necessarily whip its core base of developers into a religious frenzy, but it will sure make their bosses happy.

Thank You

By registering you become a member of the CBS Interactive family of sites and you have read and agree to the Terms of Use, Privacy Policy and Video Services Policy. You agree to receive updates, alerts and promotions from CBS and that CBS may share information about you with our marketing partners so that they may contact you by email or otherwise about their products or services.
You will also receive a complimentary subscription to the ZDNet's Tech Update Today and ZDNet Announcement newsletters. You may unsubscribe from these newsletters at any time.