MongoDB earnings announcement

[rdutt]

First Quarter Fiscal 2021 Financial Highlights

Revenue: Total revenue was $130.3 million in the first quarter fiscal 2021, an increase of 46% year-over-year. Subscription revenue was $124.9 million, an increase of 49% year-over-year, and services revenue was $5.5 million, an increase of 1% year-over-year.

Gross Profit: Gross profit was $92.7 million in the first quarter fiscal 2021, representing a 71% gross margin, compared to 68% in the year-ago period. Non-GAAP gross profit was $95.6 million, representing a 73% non-GAAP gross margin.

Loss from Operations: Loss from operations was $42.0 million in the first quarter fiscal 2021, compared to $30.6 million in the year-ago period. Non-GAAP loss from operations was $7.4 million, compared to $12.6 million in the year-ago period.

Net Loss: Net loss was $54.0 million, or $0.94 per share, based on 57.6 million weighted-average shares outstanding in the first quarter fiscal 2021. This compares to $33.2 million, or $0.61 per share, based on 54.7 million weighted-average shares outstanding, in the year-ago period. Non-GAAP net loss was $7.3 million or $0.13 per share. This compares to $12.1 million or $0.22 per share in the year-ago period.

Cash Flow: As of April 30, 2020, MongoDB had $977.5 million in cash, cash equivalents, short-term investments and restricted cash. During the three months ended April 30, 2020, MongoDB used $5.9 million of cash from operations, $1.5 million in capital expenditures and $1.1 million in principal repayments of finance leases, leading to negative free cash flow of $8.5 million, compared to free cash flow of $2.8 million in the year-ago period.

https://investors.mongodb.com/file/Index?KeyFile=404229510

[rdutt]

The preliminary numbers for this Q look good to me, but earnings guidance for Q2 is falling short of expectations.

Their revenue of $130.3M (up 46% YoY) beat the consensus estimate by over $10.6M.

Non-GAAP loss of $-0.13 beat by $0.12 (expectation was -$0.25).

Subscription revenue was up by 49%

Guidance for Q2, impacted by Covid, is $126M, which is above the consensus value of $120M. However, the non-GAAP EPS guidance for Q2 is in the range -$0.41 to -$0.38 which is worse than expected.

Full year revenue guidance is $520M to $530M (above the $518M consensus).

Stock is down about 3% after hours as I write this.

[FlyingCircus]

It’s the ongoing and increasing loss from operations that has driven me away from Mongo. Put non-GAAP lipstick on it, put gross profit lipstick on it, but they’re still and increasingly at the bottom line spending more than they’re taking in to get that growth. Negative free cash flow. At THIS point in their existence / experience, they should be on a different track to real profitability.

I’m out (have been for a while now, but love the product.)

[Smorgasbord1]

It’s the ongoing and increasing loss from operations that has driven me away from Mongo. … At THIS point in their existence / experience, they should be on a different track to real profitability.

Respectfully, I think it’s debatable what the proper point is for software companies to shift from investing for growth to achieving profits. Not that the companies nor stocks are comparable, but wasn’t the dig against Amazon for so long that it was pouring everything back into the company to achieve growth? Some think Bezos had Amazon turn a profit in 2001 Q4 just to prove they could (it was only $5M). It wasn’t until 2004 that they had a profitable year.

I’ve haven’t yet dug into the numbers just announced, but I’m OK with MDB investing in growth, as long as that growth is happening.

[invain]

Some things I see, someone please let me know if I’m way off base:

Overall revenue growth rate and subscription revenue growth rate increased from last quarter; 44% and 46% Vs 46% and 49%.

Net loss is up from same quarter last year, but is down from last quarter. Negative cash flow is also less vs last quarter.

Margins

They have almost $1 billion cash/cash equivalents, I don’t really see how they are burning through money at this point. $8.5 million in negative free cash flow also seems like a pretty small amount in the grand scheme of things.

[CompoundingCed]

I would be concerned about the revenue growth trend for Mongo. Peeling into their segments, Enterprise growth has been rather unremarkable at about 20+% (last 4 quarters were 29.0%, 16.5%, 25.8% and 33.0%). Their fastest growing segment, Atlas, has had a rather rapid deceleration (246.8%, 187.0%, 85.8% and 75.5%)

[captainccs]

Their fastest growing segment, Atlas, has had a rather rapid deceleration (246.8%, 187.0%, 85.8% and 75.5%)

The triple digit grow was off a very small base. 75% growth is phenomenal.

Denny Schlesinger
no position in MBD

[rdutt]

I’ll list my key takeaways from the MDB earnings call, and describe why NoSQL databases are such a growth phenomenon. This is based on my background as a software architect and developer.

Key Takeaways from Earnings Call

• Q1 revenue of $130M grew $46% YoY, which is higher than the 44% growth of the previous quarter. That’s extraordinary, given that the last 3 weeks (25%) of the quarter faced Covid-related headwinds.

• Revenue from Atlas, which is their cloud-based managed database service, grew 75% YoY, and represents $55M of the $130M total. So Atlas, which is subscription-based, by itself now has an annually recurring revenue run rate of $220M.

• Unlike many other companies, they did not shy away from providing full year guidance, which, they estimate to come in between $520M and $530M. If they beat that range by 8%, like they did this past Q, they would gross $570M this year. Their current market cap of $11.5B represents a reasonable 20x multiple of this year’s expected sales.

• Work from home has accelerated digital transformation to the cloud, and MDB is a beneficiary. Over 40,000 people registered for their MongoDb Live event. In comparison, last year, only 2,000 people attended.

• “During the first quarter, we grew our customer base by over 1,400 customers sequentially, bringing our total customer count to over 18,400, which is up from over 14,200 in the year ago period.”

• “We had another quarter of net ARR expansion rate above 120% despite the impact of the economic environment. We ended the quarter with 780 customers with at least $100,000 in ARR and annualized MRR, which is up from 598 in the year ago period.”

Why MongoDB Adoption is Growing So Fast
MongoDB is by far the #1 player in NoSQL databases. The total global database market is estimated to be about $70B this year, so MongoDB has a huge TAM opportunity here. There are two primary benefits driving the adoption of NoSQL databases over SQL.

No pre-defined schema required
Suppose you are a health insurance company building a database for insured members. If you’re using Oracle, or any other SQL database, you have to decide in advance how to design every table and what fields to put in each table. This is called a database schema, and it’s difficult to get this right the first time. If you already have millions of rows of members in your table, and you need to add a column like “family history of diabetes”, then a SQL DB can sometimes lock out your entire table from being updated while it adds that column, and you can even have a production outage. So you need to a schedule maintenance period where your DB is out of service just to update that table.

There is no such restriction with MongoDB, because there’s no need to define a schema in advance. Every item in the table is an unstructured “document” containing a variable number of fields or lists, and you can add fields to it at any time without any maintenance or down time. It’s perfect, for example, for storing an Electronic Medical Record (EMR) with information about prescriptions that could vary in future.

Horizontally Scalable
What happens to your SQL database server when traffic explodes and its memory and CPU exceed 95% and your users get locked out? Well, the only way to scale that server is to shut it down (there’s that down time again), and migrate to a bigger one with twice the memory and CPU. But this type of vertical scaling has its limits. Another way to scale it would be to add read replicas, which are additional database servers that are limited to doing read operations only. But that’s no good if you have a write-heavy workload.

Enter MongoDB. It’s implemented as a cluster of database servers. So it can be easily scaled horizontally just by adding more database servers to the cluster. The servers work in parallel, and the entire cluster can be both written to and read from. Yes, you do have to sacrifice strongly consistent reads if you want maximum performance. However, MongoDB has added support for ACID (Atomic) transactions, if you need them.

Every medium and large enterprise increasingly needs to analyze enormous amounts of data (aka Big Data), so you can see why horizontal scalability for performance is such a big deal. The traditional SQL DBs are just not cutting it any more.

-Ron

[SaulR80683]

Ron, that was the clearest and most understandable explanation of the advantages of MDB that I have ever read. It made even me, a confirmed Mongo skeptic because of its ever continuing losses, consider doing some more evaluation. Thanks,
Saul

[SaulR80683]

Ron, I don’t usually pay any attention to GAAP figures, but just out of curiosity, since you follow Mongo, do you have any idea why Mongo’s GAAP losses just seem to grow and grow. The figures of $54 million, (roughly 42% of revenue) and 94 cents a share, for one quarter’s GAAP losses just caught my eye, and looked enormous.

Thanks

Saul

[jwiest]

No pre-defined schema required

I’m sorry, this is completely untrue. I don’t mean to be rude, this entire section is totally misleading.

If you’re using Oracle, or any other SQL database, you have to decide in advance how to design every table and what fields to put in each table. This is called a database schema, and it’s difficult to get this right the first time.

Yes, you have to define it in advance, but you have to do that with NoSQL too. With SQL, you don’t have to get it right the first time, you can easily add/drop columns/indexes, etc…I work in an organization where we do this all the time…and yes, to millions of rows.

There is no such restriction with MongoDB, because there’s no need to define a schema in advance.

Perhaps in the simplest of tutorial examples, this statement could be true. But for all real intents and purposes it is not. With NoSQL, in order to search your data you still need columns and indexes and whatnot, and if you don’t define things properly it’s a MAJOR pain to refactor it. If you don’t define a field, you can’t search on it, and it’s difficult to add such fields later. It’s barely organic. SQL is more organic.

It’s perfect, for example, for storing an Electronic Medical Record (EMR) with information about prescriptions that could vary in future.

This is true…for storage…but if you want to get to the data, to search for it in some way, you have to identify it with keywords, pull data out so that it’s available in a field, etc. You can’t just stuff a bunch of random PDFs into a Mongo database and expect to be able to find one of the later by address…you still have to pull the address out into a searchable field in order to get to it. It’s not magic. It’s not intelligent. It can’t see “oh, that PDF seems to have an address top left, while this one has one top right…and that one doesn’t have an address because it’s a picture of a dog…and hey, I even know what an address is!”. That AI-level technology doesn’t exist yet. Too often people use this kind of “magical language” when discussing the benefits of NoSQL, and it’s completely misleading. Humans still have to provide the structure by which to get the data back out, and this is no different from SQL.

Horizontally Scalable

Ah, there we go. The biggest (and only real) benefit of NoSQL in general. This benefit is huge, but it can also be a drawback because again, you have to structure how the data is split horizontally and you have to foresee this in advance. If you structure the splits wrong, you could end up having one or two servers with most of the data, and a dozen other servers with a minimum of data…and migrating THAT to a more efficient structure is time-consuming and probably requires down-time.

And while horizontal scaling is performant for document storage, overall it really depends on the kind of data you are querying. Nothing will beat the performance of searching “index on last_name” if you can keep that all in RAM on one server. SQL databases are still the most efficient and effective solution for most people and most businesses, and you can get most of the benefits of NoSQL just by storing “documents” in a BLOB field.

– full disclosure: I did own some MDB before Covid but sold to simplify my portfolio and have a backstop in case of job loss. I think MDB can do well, so my commentary is not on the company’s prospects…only the hype that seems to surround it.

[rdutt]

Ron, that was the clearest and most understandable explanation of the advantages of MDB that I have ever read.

Thanks, Saul!

I don’t usually pay any attention to GAAP figures, but just out of curiosity, since you follow Mongo, do you have any idea why Mongo’s GAAP losses just seem to grow and grow.

The biggest factor in the GAAP loss seems to be Stock Based Compensation (SBC). That grew from $14M in the year ago quarter to $30M this quarter.

The second biggest factor is the amortization expense on debt after they acquired Realm, mlab and Wired Tiger. That expense grew to $12M in Q1.

Add the $30M in SBC to the $12M in debt service, and you already get $42M in expenses that don’t get counted in non-GAAP earnings. None of the analysts on the call raised any questions about these expenses. MDB has a pretty healthy balance sheet, with $1B of cash and short term investments on hand.

I know you like pay to more attention to non-GAAP figures, and, as you know from the earnings call, the loss narrowed to $7.3M this past Q from $12M in the year-ago Q.

Going forward, they want to accelerate hiring, because they see engineering and marketing talent coming on the market now due to layoffs in industries like hospitality, retail and travel.

Note, I am more of a techie than a finance person, so please treat the analysis above accordingly.

Reference: https://investors.mongodb.com/file/Index?KeyFile=404229510

Ron

[rdutt]

Hi jwiest,

Thanks for your thoughts on MongoDB. I agree with you that both relational and NoSQL DBs have their pros and cons. I hope this thread doesn’t devolve into a pure tech debate, since that’s not the primary purpose of this board. Also, if you have SQL skills, don’t worry, they’ll continue to be valuable.

Anyway, I have direct experience with trying to add a column to a production MySQL database with 8 million rows in the middle of a busy business day. It was not a fun experience. Queries got locked out, and caused a temporary outage for our users.

That’s because in MySQL 8, the ALTER TABLE … ADD COLUMN command does lock the table, as documented in this article:

https://dba.stackexchange.com/questions/211346/does-alter-ta…

So, whenever we needed to update our schema, especially on that big a table, we would schedule it in the dead of night, as part of scheduled maintenance.

As for your comments about defining a schema in advance, let me quote directly from the Mongo docs:

Flexible Schema
"Unlike SQL databases, where you must determine and declare a table’s schema before inserting data, MongoDB’s collections, by default, does not require its documents to have the same schema. That is:

• The documents in a single collection do not need to have the same set of fields and the data type for a field can differ across documents within a collection.

• To change the structure of the documents in a collection, such as add new fields, remove existing fields, or change the field values to a new type, update the documents to the new structure.

• This flexibility facilitates the mapping of documents to an entity or an object. Each document can match the data fields of the represented entity, even if the document has substantial variation from other documents in the collection."

https://docs.mongodb.com/manual/core/data-modeling-introduct…

And, yes, you still do need to define indexes in MongoDB to make searching fast. My point is that you can start with a minimum number of required fields, and an index, and then each collection can have an additional number of variable fields, as your business needs evolve.

There are actually at least two types of NoSQL databases. One type is a key/value store, like Cassandra (the database used by Facebook) or Amazon’s DynamoDB. The other type is document-oriented NoSQL DB like MongoDB. The advantage with the latter is that you can search for elements even within deeply nested JSON structues. Note that a “document” here is not a PDF - it refers to a data format called JSON which is used to represent fields within data, including nested fields.

I hope this clears things up.

[jwiest]

Thanks for the response. This:

Note that a “document” here is not a PDF - it refers to a data format called JSON which is used to represent fields within data, including nested fields.

…is what I was getting at. However you provide the searchable content, it still has to be extracted by someone and set up. Never mind that your element structure and what each element actually means has to be documented somewhere otherwise how will anyone know what to search for? If your data structure becomes “loosy-goosy” because you have a lot of documents with oddball fields, managing that could become a chore in its own right.

There are definitely benefits to NoSQL, but I felt that your earlier description implied that it all “just worked” somehow, which is what I see a lot of NoSQL enthusiasts proclaim.

[RafesUserName]

Just to echo what some others have already alluded to in this thread, but in more general terms: Be careful about trying to list out MongoDB’s features like it is a unique product that can replace all other companies or databases. This approach provides a false view. Databases are a tool that need to fit the job. You can’t use a screwdriver to change a tire.

1. Databases are just one of many ways to store data. Data can even be stored in an actual text file on disk if that is all you need. I can dump JSoN to a text file with a couple lines of code (and do, often). Once you determine your application needs a database backing its data storage, you have to choose the one that fits your needs. Not all applications should use a NoSQL database. There are pros and cons that are lower level, and more important, then administrative features. If NoSQL is not a fit then MongoDB isn’t part of the conversation, and rightfully so.

2. Schemas are very, VERY, good. A schema is like a contract with users of your system. It protects you and them from doing bad things. Here is a common story to illustrate this: Let’s say I write a tool that gets a date from a database so I can look up a stock quote. Pretty easy to do and it works so you release your tool for your team to use. A few days later someone on the team uses your tool but it throws an error saying something about a stock query going bad. You run it on your end and it works fine! What is going on?! After an hour of tinkering you find out the whole issue is caused because someone inserted the string “May 2nd, 1979” instead of the date object for that day and only this one time, so it isn’t obvious at all. So what do you do now? I find most coders will just code around this. They will add more code to detect if the type given is a string or a date object and then they add more code to handle the unexpected data type. What you end up with is bloated code all over the place (because you have a lot of coders writing the same work-arounds in multiple high-level tools and libraries) AND a messy database. This is a real, serious and sadly common hidden cost to technology. It is a form of debt known as “technical debt”, and you have to pay for it eventually. It slows down work and makes migratations more complex and costly.

If you don’t use the DB itself to enforce a schema, you just push the responsibility to the next level up in the stack, or worse, ignore the need and code your way in to trouble over time. Often it is the most efficient to let the database do the gatekeeping.

3. MongoDB is not the only NoSQL option. AWS has their own for example (https://aws.amazon.com/dynamodb). That said, MongoDB is the go-to choice when all things are equal, in my opinion. Still, there will be new takes on database patterns in the future, as there were in the past. It is just a lower layer in a stack.

At their age and level of brand awareness, if MDB isn’t profitable, it is hard for me to understand why, and that is why I’m not a shareholder, but still use the product. Now if MongoDB is developing entirely new disruptive options beyond NoSQL, that would be interesting. Even so I’d need to see it winning in the market first as investing too early would be akin to buying a biotech because of a promising phase 2 trial. In the meantime, Atlas and some of their management tools do look nice. I’m willing to change my mind in the future. I’ll keep it on my watch list for now. Perhaps in 2 more Qs the picture will sharpen. I expected the pandemic to hurt them more than help. Who wants to approach a migration at a time like this?! Not unless it is part of a critical one (read: first time to the cloud / no previous database in use). If I have a company running on a less-than-perfect database, but running none the less, I would be pushing a migration effort for a few months. Been there.

[Smorgasbord1]

OK, third time responding to this (I trashed the other two replies before sending since they were too technical and not investing related).

1. I can dump JSoN to a text file with a couple lines of code (and do, often).

Note that MongoDB is literally a database of JSON documents. That’s what’s meant by a document-oriented database. Internally MongoDB uses BSON (binary form of JSON) for efficiency. https://www.mongodb.com/json-and-bson

2. If you don’t use the DB itself to enforce a schema, you just push the responsibility to the next level up in the stack, or worse, ignore the need and code your way in to trouble over time.

There are drawbacks to enforcing schemas at the database level, especially in today’s corporate world, which have disparate data sets being merged/analyze, and which have orders of magnitude more data coming in, not just from many departments in a company, but from more adoption of IoT (lots of little devices sending all kinds of data back in). Document-oriented databases let you store data as it comes, and then you program (this is simplified) based on keys. So, it doesn’t matter that two different devices send data using different schemas as long as they use the same key for the same data - and if not you can program to treat the two keys as one and program to convert the data to some normalized view as needed.

3. MongoDB is not the only NoSQL option. AWS has their own for example…

Yes, and dynamoDb was one of the first (along with Google’s BigTable). These NoSQL databases were needed since both those companies had much more data than traditional databases could handle.

Note that since then, Amazon introduced documentDB, which is based on an older open-source version of Mongo. It’s less featured and only runs on AWS of course. MongoDb was created when the company was doing a PaaS product and didn’t see a suitable database, so worked on that and then realized that lots of other people would want the same capabilities.

The layman’s take-away for NoSQL document-oriented databases is that they hold lots of data more easily and they’re really flexible in that you can get your data stored without worrying about converting schemas. They’re not for every use case, but they are for most of the use cases that many companies are needing as their data grows in both size and variation.