6 ms·

MongoDB's stock price is quite remarkable, given how dismissive a lot of people (including myself) on HacherNews have been of their offering. It goes to show t

MongoDB's stock price is quite remarkable, given how dismissive a lot of people (including myself) on HacherNews have been of their offering. It goes to show that HackerNews consensus != reality. I do wonder where/how Mongo makes their money - if anybody has some insight, please share.

hewrin10 6y ago
HackerNews is wildly detached from reality
- mekster 6y ago
  No, I think it's more truthful than any other place with bunch of noises.
- Nullabillity 6y ago
  Alternatively: capitalism optimizes for charlatans, not quality.
- dang 6y ago
  Maybe so, but please don't post unsubstantive comments here.
skolsuper 6y ago
https://www.prnewswire.com/news-releases/mongodb-inc-announces-third-quarter-fiscal-2021-financial-results-301188829.html https://www.prnewswire.com/news-releases/mongodb-inc-announc... - Revenue: Total revenue was $150.8 million in the third quarter fiscal 2021, an increase of 38% year-over-year. Subscription revenue was $144.1 million, an increase of 39% year-over-year, and services revenue was $6.7 million, an increase of 19% year-over-year. - Gross Profit: Gross profit was $104.7 million in the third quarter fiscal 2021, representing a 69% gross margin, compared to 71% in the year-ago period. Non-GAAP gross profit was $108.6 million, representing a 72% non-GAAP gross margin. - Loss from Operations: Loss from operations was $58.1 million in the third quarter fiscal 2021, compared to $38.7 million in the year-ago period. Non-GAAP loss from operations was $16.0 million, compared to $14.3 million in the year-ago period. - Net Loss: Net loss was $72.7 million, or $1.22 per share, based on 59.4 million weighted-average shares outstanding in the third quarter fiscal 2021. This compares to $42.4 million, or $0.75 per share, based on 56.4 million weighted-average shares outstanding, in the year-ago period. Non-GAAP net loss was $18.2 million or $0.31 per share. This compares to $14.6 million, or $0.26 per share, in the year-ago period. - Cash Flow: As of October 31, 2020, MongoDB had $966.8 million in cash, cash equivalents, short-term investments and restricted cash. During the three months ended October 31, 2020, MongoDB used $8.1 million of cash from operations, $5.6 million in capital expenditures and $1.2 million in principal repayments of finance leases, leading to negative free cash flow of $14.9 million, compared to negative free cash flow of $13.1 million in the year-ago period.
- deleted 6y ago
  [deleted]
- hodgesrm 6y ago
  I'm always kind of amazed at the low services number on MongoDB earnings reports. It's 4-5%. This seems unusually low for enterprise database companies.
  - akg_67 6y ago
    As percentage of total revenue, MongoDB service revenue is about half compared to what Oracle generates. My guess is customer churn is much higher for MongoDB.
    - gqewogpdqa 6y ago
      Hmmm. Isn't customer churn public? Anyways, my guess is that the product is 1) much easier to use (less bells and whistles) 2) mongodb provides more configuration etc without charging for it.
- thu2111 6y ago
  MongoDB Atlas's business model seems very, very odd to me. The prices for hosted Mongo are so high that I really find myself asking who is paying for this and what the target market is. In particular I wonder how they can possibly be losing money when charging such insane markups unless they have virtually no customers. For a dedicated database that has 32 GB of RAM, 8 virtualised CPUs, and only 160GB of storage you will pay $2 an hour! That's $17,520 a year for a database with the same level of compute and far less storage than my laptop. I realise a big part of their target market is firms who are convinced they either can't hire skilled sysadmins or are convinced their time is worth more than the US President but at $17,520/yr for a tiny database it only takes two or three of those before you could, in fact, hire a full time sysadmin in a cheap location. And there's no way that maintaining these things would require an FTE, it's not even close to being a full time job. So how do the economics of this work out? Can anyone explain to me? My best guess is that Atlas customers are companies that are totally price insensitive and have some sort of "everything must be cloud managed without exception" rule imposed from the top down. As Mongo is licensed such that only they can run a hosted service, such customers would find themselves forced by internal policy into paying whatever price Atlas charges. This would also explain their very low services revenue. But I don't know that, it's just a guess.
antman 6y ago
HN consesus!=Market consesus Reality!=Market consensus (startups that lost their data using the first versions of mongo) More often: HN consensus=Reality At least ES had the decency to tell you it might lose your data.
vosper 6y ago
I’m on record here saying I really dislike Mongo DB and never want to work with it again. I stand by that. But Atlas is a really nice product (to work around the inherent failings of Mongo, but hey, you’re locked in already). Want to look at something in a backup? Select your snapshot, download and run a special binary, and point your client at it. It takes like 30 seconds to be pulling data from any backup. I did it this week. Now, would I have been able to make the mess I needed to recover from if I’d been using Postgres? No, of course not. But like I said: you’re locked-in already. Edit: Mongo is a special kind of lock-in: your code ends up so much more tightly-coupled, and hard to extricate, because of the Mongo pattern of making you do the work to ensure consistency and correctness. I can’t imagine it was planned, but it’s highly effective: for many companies it’s just too much work, too expensive, and the benefits are too opaque (“but the application works now, and you’re telling me you want to switch databases and it’ll take how long?!”) for others to buy into. I’d call it clever, but I think it’s a profitable accident that’s a braking force on the progress of many teams.
bawolff 6y ago
I think people are dismissive of the product not the business. Its not a contradiction to dislike mongodb technically well still thinking its a good business.
htsh 6y ago
I have used Mongo for 9 years. First at a game company, then for several prototypes that made it to production in my current role. We have not lost data once. Many of my friends at medium-sized companies use Mongo for much larger projects and have not lost data a single time, either. And it is it not just me and my friends -- HSBC recently announced they are moving 65 of its relational databases to mongodb. I am not sure that is wise, but I think it furthers my view that data-loss is not a concern in many contexts. The data-loss thing was most certainly real, but has not been since wiredtiger if one manages it the right way or uses it as a service. I would not say that I would say that HN != reality, maybe !== reality :). Neither side of the debate is wholly right, and neither is wholly wrong. The reason I use it is that for many projects, all you need is a relatively fast JSON document store, and mongo is so developer-friendly such that speed-to-prototype is so much shorter than anything else I have used in 25 years of building database-backed applications. Rethink was the only product that I would have used in its place and I was extremely sad to see it go. I agree with the commenter elsewhere in the belief that it would have thrived had it survived. I was using it for my personal/learning projects and was ready to switch everywhere. We have stuck with Mongo in production for a few products, one relatively large, and I think if you have separated your concerns well-enough, it is okay developing in Mongo while leaving yourself a path to postgresql or something else. You need to prove, first, that the thing you are building is useful, and Mongo will let you get to that really fast. I believe what is happening here is that the happy folks are quiet, and the aggrieved folks' experiences are real but it likely was a bad fit for their particular situation. For the subset of situations where we use it, it has allowed my teams quickly in our experimental work. All of that said, I work in an innovation space where we throw a lot of things at the wall to see what sticks, and our time-to-prototype is often a few months at most. For us, it has been a godsend, but our situation is rather unique. -h
- eternalban 6y ago
  > All of that said, I work in an innovation space where we throw a lot of things at the wall to see what sticks, and our time-to-prototype is often a few months at most. For us, it has been a godsend, but our situation is rather unique. The very RAD reasons you note regarding Mongo also encourage Mongo Cancer (tm). What is Mongo Cancer you ask? It is the phenomena where Mongo use is manifest from API to home-grown "relational logic" in business tier. This simply doesn't happen with any other NoSQL DB afaik, but Mongo Cancer uniquely marches right up to the user's face in the API. > I think if you have separated your concerns well-enough, it is okay developing in Mongo while leaving yourself a path to postgresql or something else. I'll hold you to that "I think" and assume you have never actually done this. Because Mongo Cancer patients typically love the RAD aspect of grabing JSON hot off the http stack and shoving it in the "database", touching every API in the way. The last M.C. project I saw required effectively a rebuild to actually swap the misused Mongo. tldr; Mongo Cancer is very easy to catch but requires very expensive surgery to cure.

hewrin10 6y ago

HackerNews is wildly detached from reality

mekster 6y ago
No, I think it's more truthful than any other place with bunch of noises.
Nullabillity 6y ago
Alternatively: capitalism optimizes for charlatans, not quality.
dang 6y ago
Maybe so, but please don't post unsubstantive comments here.

skolsuper 6y ago

https://www.prnewswire.com/news-releases/mongodb-inc-announces-third-quarter-fiscal-2021-financial-results-301188829.html https://www.prnewswire.com/news-releases/mongodb-inc-announc... - Revenue: Total revenue was $150.8 million in the third quarter fiscal 2021, an increase of 38% year-over-year. Subscription revenue was $144.1 million, an increase of 39% year-over-year, and services revenue was $6.7 million, an increase of 19% year-over-year. - Gross Profit: Gross profit was $104.7 million in the third quarter fiscal 2021, representing a 69% gross margin, compared to 71% in the year-ago period. Non-GAAP gross profit was $108.6 million, representing a 72% non-GAAP gross margin. - Loss from Operations: Loss from operations was $58.1 million in the third quarter fiscal 2021, compared to $38.7 million in the year-ago period. Non-GAAP loss from operations was $16.0 million, compared to $14.3 million in the year-ago period. - Net Loss: Net loss was $72.7 million, or $1.22 per share, based on 59.4 million weighted-average shares outstanding in the third quarter fiscal 2021. This compares to $42.4 million, or $0.75 per share, based on 56.4 million weighted-average shares outstanding, in the year-ago period. Non-GAAP net loss was $18.2 million or $0.31 per share. This compares to $14.6 million, or $0.26 per share, in the year-ago period. - Cash Flow: As of October 31, 2020, MongoDB had $966.8 million in cash, cash equivalents, short-term investments and restricted cash. During the three months ended October 31, 2020, MongoDB used $8.1 million of cash from operations, $5.6 million in capital expenditures and $1.2 million in principal repayments of finance leases, leading to negative free cash flow of $14.9 million, compared to negative free cash flow of $13.1 million in the year-ago period.

deleted 6y ago
[deleted]
hodgesrm 6y ago
I'm always kind of amazed at the low services number on MongoDB earnings reports. It's 4-5%. This seems unusually low for enterprise database companies.
- akg_67 6y ago
  As percentage of total revenue, MongoDB service revenue is about half compared to what Oracle generates. My guess is customer churn is much higher for MongoDB.
  - gqewogpdqa 6y ago
    Hmmm. Isn't customer churn public? Anyways, my guess is that the product is 1) much easier to use (less bells and whistles) 2) mongodb provides more configuration etc without charging for it.
thu2111 6y ago
MongoDB Atlas's business model seems very, very odd to me. The prices for hosted Mongo are so high that I really find myself asking who is paying for this and what the target market is. In particular I wonder how they can possibly be losing money when charging such insane markups unless they have virtually no customers. For a dedicated database that has 32 GB of RAM, 8 virtualised CPUs, and only 160GB of storage you will pay $2 an hour! That's $17,520 a year for a database with the same level of compute and far less storage than my laptop. I realise a big part of their target market is firms who are convinced they either can't hire skilled sysadmins or are convinced their time is worth more than the US President but at $17,520/yr for a tiny database it only takes two or three of those before you could, in fact, hire a full time sysadmin in a cheap location. And there's no way that maintaining these things would require an FTE, it's not even close to being a full time job. So how do the economics of this work out? Can anyone explain to me? My best guess is that Atlas customers are companies that are totally price insensitive and have some sort of "everything must be cloud managed without exception" rule imposed from the top down. As Mongo is licensed such that only they can run a hosted service, such customers would find themselves forced by internal policy into paying whatever price Atlas charges. This would also explain their very low services revenue. But I don't know that, it's just a guess.

antman 6y ago

HN consesus!=Market consesus Reality!=Market consensus (startups that lost their data using the first versions of mongo) More often: HN consensus=Reality At least ES had the decency to tell you it might lose your data.

vosper 6y ago

I’m on record here saying I really dislike Mongo DB and never want to work with it again. I stand by that. But Atlas is a really nice product (to work around the inherent failings of Mongo, but hey, you’re locked in already). Want to look at something in a backup? Select your snapshot, download and run a special binary, and point your client at it. It takes like 30 seconds to be pulling data from any backup. I did it this week. Now, would I have been able to make the mess I needed to recover from if I’d been using Postgres? No, of course not. But like I said: you’re locked-in already. Edit: Mongo is a special kind of lock-in: your code ends up so much more tightly-coupled, and hard to extricate, because of the Mongo pattern of making you do the work to ensure consistency and correctness. I can’t imagine it was planned, but it’s highly effective: for many companies it’s just too much work, too expensive, and the benefits are too opaque (“but the application works now, and you’re telling me you want to switch databases and it’ll take how long?!”) for others to buy into. I’d call it clever, but I think it’s a profitable accident that’s a braking force on the progress of many teams.

bawolff 6y ago

I think people are dismissive of the product not the business. Its not a contradiction to dislike mongodb technically well still thinking its a good business.

htsh 6y ago

I have used Mongo for 9 years. First at a game company, then for several prototypes that made it to production in my current role. We have not lost data once. Many of my friends at medium-sized companies use Mongo for much larger projects and have not lost data a single time, either. And it is it not just me and my friends -- HSBC recently announced they are moving 65 of its relational databases to mongodb. I am not sure that is wise, but I think it furthers my view that data-loss is not a concern in many contexts. The data-loss thing was most certainly real, but has not been since wiredtiger if one manages it the right way or uses it as a service. I would not say that I would say that HN != reality, maybe !== reality :). Neither side of the debate is wholly right, and neither is wholly wrong. The reason I use it is that for many projects, all you need is a relatively fast JSON document store, and mongo is so developer-friendly such that speed-to-prototype is so much shorter than anything else I have used in 25 years of building database-backed applications. Rethink was the only product that I would have used in its place and I was extremely sad to see it go. I agree with the commenter elsewhere in the belief that it would have thrived had it survived. I was using it for my personal/learning projects and was ready to switch everywhere. We have stuck with Mongo in production for a few products, one relatively large, and I think if you have separated your concerns well-enough, it is okay developing in Mongo while leaving yourself a path to postgresql or something else. You need to prove, first, that the thing you are building is useful, and Mongo will let you get to that really fast. I believe what is happening here is that the happy folks are quiet, and the aggrieved folks' experiences are real but it likely was a bad fit for their particular situation. For the subset of situations where we use it, it has allowed my teams quickly in our experimental work. All of that said, I work in an innovation space where we throw a lot of things at the wall to see what sticks, and our time-to-prototype is often a few months at most. For us, it has been a godsend, but our situation is rather unique. -h

eternalban 6y ago
> All of that said, I work in an innovation space where we throw a lot of things at the wall to see what sticks, and our time-to-prototype is often a few months at most. For us, it has been a godsend, but our situation is rather unique. The very RAD reasons you note regarding Mongo also encourage Mongo Cancer (tm). What is Mongo Cancer you ask? It is the phenomena where Mongo use is manifest from API to home-grown "relational logic" in business tier. This simply doesn't happen with any other NoSQL DB afaik, but Mongo Cancer uniquely marches right up to the user's face in the API. > I think if you have separated your concerns well-enough, it is okay developing in Mongo while leaving yourself a path to postgresql or something else. I'll hold you to that "I think" and assume you have never actually done this. Because Mongo Cancer patients typically love the RAD aspect of grabing JSON hot off the http stack and shoving it in the "database", touching every API in the way. The last M.C. project I saw required effectively a rebuild to actually swap the misused Mongo. tldr; Mongo Cancer is very easy to catch but requires very expensive surgery to cure.