Cutting through the FUD on MDB

Cutting through the FUD on MDB

Introductory aside… There are a lot of tech- and non-tech folks not up on the whys and wherefores of NoSQL databases. (Even a former DBA was very confused recently.) If you are unsure about what MongoDB offers with document-based NoSQL engine, or, relatedly, Elastic with their search-based NoSQL engine, I highly recommend this writeup (coincidently from Amazon!) explaining the various flavors of NoSQL database, the pros/cons each has against SQL relational database, and the preferred use cases for each. https://aws.amazon.com/nosql/

Relational databases have historically been great for transactional data. [A transaction is one where you need to be sure ALL data changes complete as a whole, else it is rolled back. A simple transaction: you moving money from your checking to savings. You wouldn’t be terribly happy if $1000 left your checking and never appeared in your savings, and the bank wouldn’t be happy with the inverse.] Document-based databases are great for data collections, like diverse datasets needing categorization or a hierarchy (music or movie listings, articles, news, blogs) or e-commerce (product catalogs, shopping cart). Elastic is great for search (think of the db as one big index) so is great for time-series analysis (metrics, IoT, logging) and full text search (twitter search). [As in, something the Fool should use over the forums to provide a proper search feature.]

…Okay, back to the FUD…

Everyone is freaking out about Amazon’s new “cloud native” competing service. However, didn’t we know something was coming down the pipe? MDB signaled this heavily with the licensing change, as they made clear that they don’t want cloud providers providing managed hosting of MongoDB – as that is their new angle alongside their enterprise support over their open source software. This forces cloud providers into creating their own home-grown solution instead of using MongoDB itself.

One confusion that I have seen repeated endlessly and even in Fool articles: Amazon is NOT using MongoDB’s code base. They built an entirely new document-based NoSQL product that MIMICS MongoDB, in particular the v3.6 API standard. [The API is the way the developer interfaces with MongoDB for inserts, updates, deletes and querying.] I’ve seen hints that DocumentDB is backed by their relational database Aurora, so isn’t an entirely new product out of thin air. The net effect of mimicking the API is that this makes it compatible with your application’s code base so you can more easily swap out the data store. In addition, AWS built a migration tool that can clone your existing MongoDB v3.6 (or under) into DocumentDB. These features combine to make it so new users with existing applications can get immediately started on the new product.

If, after all that, you are still unclear about how DocumentDB is NOT using MongoDB - see this concise recap: [https://www.infoq.com/news/2019/01/aws-documentdb-mongodb]

So, a point we can all agree on is that this product and its “MongoDB” features are obviously to nab new and existing MongoDB users over to their new product, whether they are MDB customers already or not.

Not mentioned enough is that AWS’s new product DocumentDB directly competes with their prior product DynamoDB. [Later I get to Lyft, who, to be clear, is NOT on this new AWS product.]

So – AWS is bringing some competition. HOWEVER… let’s take a brief walk through history.

MongoDB has been around since 2009.

Amazon and Google and Microsoft cloud services were already competing with MongoDB via their “cloud-native” document-based NoSQL clones. Amazon has DynamoDB (since 2012). Microsoft has CosmosDB (since 2010), with a MongoDB-compatible API. Google has Cloud Firestore, part of Firebase that it acquired in 2014. Not to mention other open source document-based NoSQL stores like Cassandra (since 2008) and Couchbase (since 2010).

REGARDLESS of these competing products, MongoDB is the clear king of document databases.

REGARDLESS of these competing products that are more “native” to their respective clouds, MongoDB has thrived as a cloud-neutral provider.

REGARDLESS of many cloud services already hosting many many MongoDB containers (self managed by users themselves) and others using their “cloud native” products, MongoDB has thrived.

Why? In order of importance, IMHO:

  1. MongoDB has been the #1 product for document-based NoSQL for a decade. There is already a lot of institutional knowledge in most enterprises, and a ton of resources built around it. Developers have either already used it or can easily pick it up and learn it from a multitude of online sources with step-by-step instructions. It natively represents data as JSON for maximum compatibility. [JSON, a light-weight format for data transmission, is the most-used method today for API communication. Much simpler and more readable than (the thankfully nearly deceased) XML.]

  2. They provide a core, widely-used database that isn’t cloud-specific. MongoDB can be deployed anywhere, within a customer’s data center OR in the cloud OR now directly on mobile devices (new feature). No “cloud native” service can host at any other location outside their cloud. Any applications built using those services must be internet-connected at all times, in order to utilize it.

  3. They provide enterprise support. MongoDB [the company] sprung up to support MongoDB [the open source software]. Enterprises want to use open source solutions in their software stack as they are battle tested and not proprietary (so not locked into a vendor), but the downside is that then don’t want to wait days for an answer from communities like Stack Overflow or Google Groups to solve their immediate needs. Companies sprung up around this need as a common business model. (Also see: Elastic, Cloudera, Hortonworks, Datastax, MySQL [long ago acq by Sun then Oracle].)

  4. They provide a managed service (Atlas!) so you don’t have to administer and deploy your database architecture yourself. These tasks become even more complicated with sharded/replicated databases in today’s global economy, combined with the necessary heavy focus on security. It is simply easier to pay someone to manage your cluster instead of you needing to add multiple personnel and domain experts to manage it for you (DBA team to do installation, setup, networking, security, sharding, replication, backup plan, etc…).

  5. They are cloud-vendor neutral. This has meaning to risk-averse enterprises, but I have the feeling it is the least important reason for someone to pick MongoDB Atlas over “cloud native” solutions. Many enterprises are already “locked in” to a cloud vendor of choice.

Some final notes on recent news:

  1. Lyft news is entirely a big nothing burger. Lyft switched entirely back to AWS DynamoDB. [NOTE: the older DynamoDB, NOT the brand new DocumentDB]. It was an analyst that tied this news to MongoDB as a big loss, calling Lyft a “marquee customer”. However, we haven’t seen any such indication, and MDB themselves said it was only a customer of mLab. I concur with rdutt’s post upboard and others that Lyft was already locked in with AWS (and been using DynamoDB for years already). I am guessing they are taking their [FREE open-source] MongoDB instances that were running on EC2 VMs and converting them to DynamoDB. They are only a MongoDB “customer” through their prior use of mLab. Danstock’s post upboard stated MDB has since come out saying that Lyft wasn’t a Atlas customer, and was converting their own self-managed instances that were running a legacy version of MongoDB. Bottom line: This news is just a sales loss, of what could have been a future Atlas customer.

  2. Redhat is the only bit of Mongo news this month that has interested me, but ultimately seems another nothing burger. MongoDB changed their license for a good business reason [I can only imagine Elastic following suit]. However, Redhat’s decision simply means MongoDB is no longer packaged on their operating system releases by default. So now the user has to … wait for it… INSTALL IT. This has zero impact on MDB other than optics of the open-source community. Redhat fancies themselves as OPEN SOURCE STEWARDS and don’t like the licensing changes. This is a bit of what happened when Oracle bought Java.

At the end, a lot of huffing and puffing but I, as a software developer and investor, see very little reason to panic. I’d rather see a change in the stellar growth numbers, not freak out when Amazon is mentioned as a competitor (even though… uh… they’ve been a competitor with DynamoDB already…).

Apply all of the above to Elastic as well, as they are an extremely similar company with extremely similar business lines (enterprise support of their open-source software, and management of cloud instances). Their software is even more complex in setup and ongoing management. Less TAM than MDB ultimately, but lots of excitement as they continue to find new use cases from their customers. APM and network security monitoring are huge waves to ride right now, though.

-muji
(long MDB 8%, ESTC 3%, AMZN <1%)

129 Likes

What a quality post about MDB! This board attracts some pristine gems I must say. I’m in at 36 with MongoDB but it’s only a 5% position. It used to be 10% but decided to cut it in half and do a 5% position in Nutanix also.

I will let what they do in earnings be the measuring stick and not these vague news stories. Have been fortunate to sell the Atvi’s, Take Two’s and NVidia’s in the summer of 2018 before the slide and buy in to the cloud themes. Bumpy ride but things have really taken off. Many thanks to Saul and the other contributors of this board.

4 Likes

As an investor my regret is that the Lyft FUD didn’t drop the price further. :frowning:

As an ex-developer, the nature of the content of data changed radically with the WWW. Pre WWW data was largely transactional as CMF_muji stated. Transactional data is easy to organize because the fields are well defined. Transactional databases (SQL) were designed specifically to manage that kind of data. WWW data, the stuff you collect from website visitors, is more amorphous and therefore hard to organize into rows and columns. That’s the reason to organize it by document, to keep each collected set as a document. In both cases what you want is fast access to the data and that is accomplished by creating indexes. I would bet that Google search is 10% data (documents/web pages) and 90% indexes – just a guess.

While transactions will continue to increase, my bet (again a guess) is that WWW data will increase an order of magnitude faster. Pick up all you can and let artificial intelligence make something out of it.

Open Source was great at democratizing software but it killed a way to make a living. The abuse of open source had to bring a backlash and Mongo’s new licensing is a step in that direction. SaaS is another.

Denny Schlesinger

Disclosure: MDB is my largest high-tech position.

22 Likes

muji
Excellent post. I agree with most everything you said, and you cleared up a few things I didn’t have straight.

  1. I thought Amazon was using Mongo code base rather than emulating APIs. Very different.
  2. I thought Lyft had migrated from Mongo to DocumentDB.
  3. I was confused about the source of the initial report. I thought it was Amazon or Lyft.

And lastly, an observation. I think the MDB license revisions will be the new norm for supported open source. In time, even Red Hat (IBM) will move in this direction.

2 Likes

oh. my. God. what a great post, coming from a former DBA and integration services developer.

3 Likes

Oh the “Fog of War” surrounding MongoDB and Amazon!

I just found two very informative blog posts by:
MongoDB president Dev Ittycheria https://www.mongodb.com/blog/post/the-future-will-be-documen…
and CTO Eliot Horowitz https://www.mongodb.com/blog/post/documents-are-everywhere

My takeaway is MongoDB responded wisely, quickly, and convincingly to the Amazon DocumetDB announcement in a way that gave their sales reps solid ammunition to use if anyone was considering DocumentDB but they prudently did not put it on all the newswires (where we investors would see it readily) and publicly thumb their nose at Amazon. There are a small number of use cases where DocumentDB may be better for a few customers short term needs, but it is not a general purpose, more highly scale-able easy drop in replacement for MongoDB for most users. This will not create a significant loss of MongoDB customers over to DocumentDB in the near future.

MongoDB has a multiple year development advantage over DocumentDB, and Amazon will not make up that difference quickly. Another evidence of that advantage is the lack of functionality parity in DynamoDB, which Amazon has been working on for years. Databases are very complex software packages, and it takes a large team of expert developers years to create world class functionality. MongoDB has that advantage, and it is not going away soon.

The MongoDB response to this Amazon announcement increased my confidence in the company leadership, and my confidence in my largest stock position.

The price drop of Atlas on Azure is also very interesting. It could indicate a better relationship with Microsoft than with Amazon. If I read the benchmarks Eliot Horowitz describes in his blog correctly, that makes MongoDB on Azure cheaper per transaction than Amazon’s DocumentDB performance for read heavy transaction loads that do not use much of the new functionality added to MongoDB over the last 6 years. These read heavy (95% reads, 5% writes) loads are the only ones that DocumentDB outperforms MongoDB on a cost per transaction basis, and does not have the scale ability of Mongo. So the takeaway is: If your short term needs are read heavy and only use a small part of the old MongoDB API, and you don’t need worldwide expansion or GDPR compatibility, you can get the same price performance of DocumentDB with Atlas on Azure PLUS all the capabilities of MongoDB 4.0 for free! For everyone else, MongoDB is the clear choice. Your development path for your app is much more robust. Since investment in training your developers is so important, I would choose a database app that can be used broadly in my organization with all the advantages MongoDB brings to develop apps quickly, and that has a world class development team that is going to stay far ahead of the competition NoSQL databases for years to come.

When I first invested in MDB a year ago, my primary investment thesis was: do they have a world class development team that can stay ahead of DynamoDB and CosmosDB? I decided that was a resounding YES, and invested accordingly. That confidence is unshaken.

The one concern I have with Amazon as a competitor, is their announcement of the big new development centers in New York and Arlington VA. If they hire 25,000 developers in each location, and create world class software teams there, their ability to outperform smaller software houses for products like database software may increase. That will be a way down the road, but Amazon is signaling they want to be the premier software development company in the world. If they use their money to buy many of the best developers, that could signal a change of fate for smaller software houses. Time will tell.

My warmest thanks to Saul and the rest of the contributors to this board. I am up 85% in the last year since discovering it.

Earl

My positions:
MDB 20%
TWLO 17%
AYX 14%
ZS 11%
TTD 11%
SQ 5%
NEWR 4%
COUP 3%
ESTC 3%
OKTA 3%
ZEN 3%

19 Likes

The one concern I have with Amazon as a competitor, is their announcement of the big new development centers in New York and Arlington VA.

Amazon gave up on New York. New location not yet announced. They seem to have problems with Seattle as well.

Denny Schlesinger

1 Like