MongoDB & the Digital Tranformation

Very good thread on MDB. Great information from everyone.

I want to add a few pieces of technical information for clarity. I’m a Database Administrator with a focus on Microsoft databases (Azure & SQL Server). I apologize if this post gets too technical, keeping a lot of the technical reasons out of this but have to get some in there to describe it.

Don’t mistake MDB as a replacement for the traditional relational SQL database. MDB definitely has some huge benefits, when used correctly. The ideal application for MDB (and really, any document database) is with very large number of small transactions (IOT, water flow readers, globally distributed apps - think mobile apps). However, document databases such as MDB are NOT good at reporting/analytics.

Think about a traditional Order. If you go to Kroger to buy groceries, a traditional database will store this in two tables. One being order header and the other order detail. The order header would have information about the overall order (time of day, summarized total etc…). The order detail will have the line item of each item in the order (milk, eggs, bananas etc…). In MDB, all the order data for this transaction will be stored in a single document. This makes it very fast to write it and very fast to read this singular transaction.

Now, lets say I get to my car and realize I forgot to get the baby food. I go back in and make another transaction and get the baby food. In the traditional relational database, there is another order header and another order detail. In the MDB database, we have another document for this transaction.

Now lets say that Kroger wants to do some analytics. Maybe they want to see how many people have made multiple transactions within the same day. Maybe they want to see if they can do something to help prevent this (perhaps having items that are easily forgotten close to the checkouts). To get the data on how many people had multiple transactions in the same day, and the items bought on that second transaction is a rather easy thing in a transactional (SQL) database and this will perform pretty well overall. However, to do get the same data on a document database is a lot more painful and a lot more difficult to pull that data out. It can be done but is a lot slower.

Now, in a perfect world, neither of these analytical queries are run in the main transactional database.
In a perfect world, the data is properly ported over to an analytical-friendly place. This is where AYX, Snowflake, Azure Synapse and other things come in to play. This is where we get into AI, Big Data, Analytics etc…

However, we don’t live in a perfect world. In many many, MANY cases, organizations don’t want to incur the expensive cost of setting up a separate analytical place. The big picture is often blurred by that huge initial expense. If MDB is used, a company is probably more likely to undertake that cost. One of my clients decided to port the MDB data to a traditional SQL database analytics and reporting.

37 Likes

I seldom post these days as I try to make sure I have something value added to say. I’ve read all 21 posts in this thread. Maybe this is reiteration rather than new information. But here’s the way I see it.

If you look back over my posts on MDB you will see that I have been a huge fan. My confidence in that position was born of my 30 years experience in IT at a Fortune 50 company. There’s almost no software more sticky than a DBMS. Once a particular product has a significant presence in a company (and especially if it has become an internal standard), it takes an enormous improvement in functionality and cost (yes, both) in order to displace it. IMO, MongoDB is already the defacto standard if not the named standard for NoSQL DBMS throughout the industry.

Nevertheless, I currently have no position in MDB. How do I reconcile my strong opinion about the product and the fact that I don’t currently see it as a good investment?

Actually, Saul has already summed it up. Despite the fact that I believe long-term MDB will rule the world (allow a little hyperbole please), the numbers just don’t add up. It’s not that MDB is a bad investment, it’s just that there are other much better opportunities.

The question that I wrestle with is whether or not I invest for the “long-term”? And more fundamentally, what does “long-term” mean with respect to an investment context?

Unlike a lot of folks who follow this board, I am a fairly recent investor. The first year for which I have maintained records was 2016, so I’ve been a serious investor for something less than five years. My attitude at the time I became an attentive investor was that I was in it for the long-term and I would invest in companies that I felt had long-term potential. Admittedly, “long-term” was ill defined. I had no specific notion of what it meant, but if you had pushed up against a wall and forced me to define it, I probably would have responded, “ten years or more”.

In July of 2016 I held fifteen positions. Not a single one of those companies appear in my current portfolio which consists of six positions. In fact, of those positions I held a mere four years ago, SHOP is the only name we even see mentioned here any longer. So, whatever I may have thought was long-term, in practical terms has turned out to be considerably less than four years.

Earlier this year with what I perceived would be the impact of the pandemic on the economy, I sold every position I held and went completely to cash. Ouch! Yes, I am paying quite a penalty in capital gains tax for that. And though I am back in the market, I am holding a much larger cash position than I did previously which I consider insurance against the vagaries of the market. But my point is that I discovered that my long-term horizon was, in fact, not much more than a year or two at the most.

That brings me back to MDB. We have witnessed and taken advantage of a unique confluence of forces as the internet, cloud, big data, edge, IoT, AI/ML and a few other heretofore non-existent information phenomena coalesce to provide the unique related technologies offered by the companies in which we have invested and profited. Eventually we will see these SaaS, s/w subscription investment opportunities dry up. I think we are already seeing fewer companies offering the phenomenal growth we have seen even a couple of years ago. The law of large numbers will shrink the percentage growth rates of our existing favorites. And the needs of the enterprise will soon be pretty close to fully addressed. As there remain fewer and fewer stones to turn over there will be less new niches to fill. I anticipate that we have but five to ten more years before these fantastic investments become more mundane. We’ll be back to investments that look more like sneakers and other manufactured goods with respect to returns.

My point is not just make hay while the sun shines, but keep an eye out on the future. What will we turn to? My guess is that MDB might look pretty good when compared to other investments a few years down the road. Yes, we will have missed most of the S-curve spurt, but that “lost” opportunity is relative to the ones we’ve exploited.

Of course, I could be wrong. I don’t have a crystal ball. Even though I was in IT for 30 years and spent the last six or seven years of my career as an enterprise architect; a big picture guy with a focus on designing the IT environment of the future, I did not anticipate where we are today. What doors will quantum computing, nano technologies, advanced bio-sciences and other emerging technologies open? I don’t know. I don’t think even guys like Ray Kurzweil and other brilliant futurists who are much smarter than I know. They are just able to make a better guess. So maybe there will be new companies that addressed “needs” we aren’t even aware of today after the bleeding edge of current information age dulls. Maybe I’ll still be alive to invest in the next paradigm whatever it is. But for now, while I’m not as fickle as a day trader, I refuse to invest in a great future potential. I prefer to keep my investment dollars in great present day investments. And I watch them closely. Every quarter around earnings reports I ask myself if I have my money working as hard as it can. Every day I try to stay aware of some unforeseen event that might disrupt my investment thesis.

I forget who said it, but a quote that I think well applies to investing is: “Plan as if you will live forever, and live as if you will die tomorrow”. My implementation of that is, as I said before, I am not a day trader, I try to avoid momentum investing. I want to invest in premier companies that provide real products/services that address vital needs. And those companies have the performance numbers that demonstrate that they are the best of breed in what they do. But it’s not a marriage. I don’t plan on being there through thick and thin. In fact, I’m pretty intolerant of “thin” when it comes to investing.

Long: AYX, CRWD, DDOG, FSLY, LVGO, ZM

59 Likes

Don’t mistake MDB as a replacement for the traditional relational SQL database.

That’s not the real issue, which that the growth in database usage is much higher for NoSQL than SQL. Sure, there will always be grocery store type data, but the real growth is in IoT, mobile acquisition, and big data analytics. There’s a reason why Google and Amazon independently decided against using SQL databases and invented alternatives.

Here’s a link to MDB’s stance on SQL vs NoSQL databases: https://www.mongodb.com/nosql-explained/nosql-vs-sq

To sum up, NoSQL gives you:
• More flexible data models than rigid SQL schemas
• Cheaper horizontal scaling versus more expensive vertical scaling typically needed with SQL (a big initial driver for Amazon/Google)
• Faster queries in the real world, where SQL queries typically need table “joins”
• Easier for developers, since NoSQL data structures can mimick what they write in code

The one potential disadvantage they cite is a lack of “ACID” (atomicity, consistency, isolation, durability), but Mongo added those in its 4.0 and later versions (not available in open sources, so Amazon’s DocumentDb, for instance, doesn’t have that).

I believe the main takeaway for investors is that while there are still cases where SQL is the best choice, the number of new Use Cases where NoSQL is the best choice is growing much more quickly.

25 Likes

“NoSQL is the best choice is growing much more quickly.” no doubt but is it growing at the rate of some of our other non MDB choices? And what percentage of the growth is MDB capturing?
Because I have limited funds .And even more limited attention, and there seems to be little chatter out there about MDB. So I sold mine, but I am not adverse to buying it back .If I see it has hidden potential.
Thanks for the info about ACID. Because MDB must distance itself from the free form.

Is it growing at the rate of some of our other non MDB choices?

From Muji’s great summary (https://discussion.fool.com/dag-nabbit-i-missed-including-crwd-m… ), here are some alternatives, sorted by revenue growth:


ZM   = rev +169% !!, custs +354% !!, $NER >130%
LVGO = rev +115%, op margin +33pp, opex +50%, custs +77%, $NER 110%
CRWD = sub rev +89%, op margin +22pp, open +66%, custs 105% !!, $NER >120%
DDOG = rev +87%, custs +49%, custs>100k +89%, $NER >130%
ROKU = rev +55%, platform rev +73%, accts +37% ^^, stream hrs +49%, ARPU 28%
NET  = rev +48%, opex +35%, custs +40%, custs>100k +65%, $NER 117%
OKTA = sub rev +48%, custs +28%, custs>100k +38%, $NER +121%
**MDB  = 45.8% (sub rev 48.6%)**
COUP = sub rev +45%, op inc +577%, opex +14%
AYX  = rev +43%, custs +30%, $NER 128%
ZS   = rev +40%, op inc +36%, $NER 119%
FSLY = rev +38%, opex +41%, $NER 133%

2 Likes

‘Is it growing at a rate higher than our other than MDB choices?’

ESTC. Revenue Growth(Sub119%)53%.GM76%;24% of total revenue is sub rev
MDB. Revenue Growth (Sub49%) 46%.GM72%;43% of total revenue is Sub rev
NET. Revenue Growth 47.8%…GM77%
TWLO. Revenue Growth 56.6%(48% w/o Sendgrid)…GM54%
WORK. Revenue Growth49.6%…GM87.3%
BPRM. Revenue Growth70%. …GM90%

1 Like

Smorg, the link provided needs an ‘l’ on the end of it. Here it is for ease for anyone who wants to read it.

https://www.mongodb.com/nosql-explained/nosql-vs-sql

Yes, there are definitely more growth opportunites in IoT and mobile. The reason the link says that queries CAN be faster is because it is a very specific kind of query that is faster. This is what I obviously did a poor job of trying to describe. Application type queries are faster, reporting type queries are orders of magnitude slower in MongoDB.

MongoDB stores data in small documents in JSON format (for those who don’t know, JSON is not a friendly-reading format, its somewhat similar to HTML but that’s over-simplifying it). For very small singular purpose queries (most application queries), the kind that needs to pull the data from a single document (like the order information from my earlier example), those are MUCH MUCH faster in MongoDB. No worries about contention, blocking etc… It is very very quick to pull a single document and display that information.

Where MongoDB gets orders of magnitude worse than in a SQL database is when needing to pull back data that is stored in more than one of the documents (most reporting queries). The Kroger example of needing data to find all occurrences where an individual had with multiple transactions within a day. MDB has to open and search the JSON in each document for the requested data. This is a whole lot harder than going thru a SQL table to find the same data.

IMO, the biggest benefit for investors within the increasing needs and situations for document databases like MongoDB is in analytics. Snowflake, AYX and many others. These tools are required more than ever. Especially in IoT types of applications where there is a very very large amount of data geographically dispersed. After the data is loaded up in MDB it gets ported over using ETL tools (Azure Data Factory or AYX…) to big data platforms (Azure Synapse, Snowflake) where a smorgasbord of analytics tools (PowerBI, Databricks, Tableau… even Excel or SmartSheets) can be used to slice, dice, analyze and over-analyze. I’m over-simplifying this but that is the general flow.

Long AYX, anxiously awaiting Snowflake IPO… well maybe the Snowflake lockup expiration.

2 Likes

MDB has to open and search the JSON in each document for the requested data. This is a whole lot harder than going thru a SQL table to find the same data.

The problem is that you didn’t create structure the data in MongoDB appropriately. It reminds me of this old blog post: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never… to which the correct response was: https://ayende.com/blog/164483/re-why-you-should-never-use-m…

I won’t go into the details here - read the response post first and then the original to see what they were doing wrong.

Bottom line is that investors in MDB shouldn’t be worried that MDB is “orders of magnitude worse than in a SQL database” because with the right design it isn’t.

That said, I do completely agree with FinallyFoolin on:
IMO, the biggest benefit for investors within the increasing needs and situations for document databases like MongoDB is in analytics. Snowflake, AYX and many others. These tools are required more than ever. Especially in IoT types of applications where there is a very very large amount of data geographically dispersed.

6 Likes

To be clear, I’m not saying a SQL DB is orders of magnitude better than MongoDB. There are tons of situations where Mongo is orders of magnitude better (such as oil flows and IoT). However, when it comes to reporting and analytics, SQL is orders of magnitude better.

The linked articles are good and very on-target. Of course if we know what will be needed to be reported on, its easier to design for it. However, that’s not how most software is created. The focus is usually on getting the application running and the types of data needed to store that and reporting is more of an afterthought. Heck, most of the time, its not really even known what the most effective ways to slice and dice the data will be, and it changes. As these articles point out very well, there is actually a lot more flexibility in the SQL database than the MongoDB because once you’ve gone down the path of the design in Mongo, it is a huge pain to change it. For example, in the second article with the better design on what shows a particular actor is in, what happens if management wants to find actors who were in the same TV shows but never the same episodes and group those together for some analysis? This can be done in a SQL database with a simple query but would need to be ported out of MongoDB (or a separate grouping created just for this query).

I think we’re out of bounds here on the financial part. I apologize. The main point for those reading this is what we agree on. Looking forward to the Snowflake IPO.

To be clear, I’m not saying a SQL DB is orders of magnitude better than MongoDB. There are tons of situations where Mongo is orders of magnitude better (such as oil flows and IoT). However, when it comes to reporting and analytics, SQL is orders of magnitude better.

That’s not really true either, especially when you start getting into multi-level, multi-table joins, aggregation, etc.

Many times a badly written reporting or analytics query will bring your nicely-tuned RDBMS to a grinding halt. That’s why these functions are often off-loaded to a different system.

It’s a huge topic in any database.

But here’s just one example from the other side.
https://developers.amadeus.com/blog/how-we-stretched-mongodb…
This post will show why and how we stretched MongoDB, turning it from the well-known developer-friendly online transaction processing (OLTP) document store, into a powerful interactive online analytical processing (OLAP) engine.

I love MongoDB as a product and as an investment. I’m a bit wary though of how much of “Oracle’s lunch” it can really eat. What are they now on market cap? 15:1 or something. So a few more doublings of MDB would see them at about parity. Now, look at all the other things Oracle does apart from SQL. Including it’s own cloud provision.

4 Likes

I read these pros and cons, but I don’t know enough to weight them. It does see clear that both SQL and noSQL have their advantages , most companies will use both but the latter is newer and growing faster. For me that is not quite enough to keep it in my portfolio. Too many unknowns compared to other choices, ones more directly benefiting from Covid related business changes.