8 ms·

With four years of hindsight, the estimate of DBaaS and managed database hosting companies of being <10M revenue stood out at me. MongoDB Atlas hit $85M revenue

With four years of hindsight, the estimate of DBaaS and managed database hosting companies of being <10M revenue stood out at me. MongoDB Atlas hit $85M revenue in Q4 2020 (https://www.fool.com/earnings/call-transcripts/2021/03/10/mongodb-inc-mdb-q4-2021-earnings-call-transcript/ https://www.fool.com/earnings/call-transcripts/2021/03/10/mo...), which means that assuming RethinkDB's estimates were correct, the market they wrote off as too small was actually about to explode into something much larger. That's not to say that they would have succeeded if they'd gone after that though; instead we might have a blog post about how they correctly predicted where the market would go and simply ran out of money before the market got there.

alexashka 6y ago
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.
- 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.
nodesocket 6y ago
I firmly believe that RethinkDB could have been a huge player along with the likes of MongoDB and Elasticsearch if they could have gotten additional funding or focused more on business development. Note: both MongoDB and Elasticsearch are now hugely successful public companies. - Changefeeds were so useful and still to this day not really matched in quality. - Official client libraries were very high quality. I mainly used Node.js. - Performance (reads and writes) was impressive. - Setting up a highly available cluster with sharding was incredibly easy with a few clicks and types in the aforementioned web U/I. - Their web U/I was the best to ship with a database at the time. I still wear my RethinkDB shirt around, and it was a pleasure meeting one of the founders Michael Glukhovsky in San Francisco when they were still moving and grooving. The best technology and product doesn't always win.
- wishinghand 6y ago
  I liked the RethinkDB API better too. Seemed more intuitive and you could do something like joins in it too.
  - dkersten 6y ago
    I loved the API. It made it very clear and easy to think about how my data is being accessed, how my indexes are used etc. I miss working with rethinkdb :(
- WrtCdEvrydy 6y ago
  Honestly, as the person who is ending up having to do the RethinkDB migration... it's the lack of an AWS hosted solution that killed it for us. Even the import is a great experience and moving to MongoDB wasn't too bad (after a bit of cleanup)
  - nodesocket 6y ago
    Interesting, RethinkDB was really easy to setup. Three EC2 instances (cluster), install their apt repo, and install. There were a few config options[1], but really minimal and clean. [1] https://rethinkdb.com/docs/config-file/ https://rethinkdb.com/docs/config-file/

alexashka 6y ago

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.
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.

nodesocket 6y ago

I firmly believe that RethinkDB could have been a huge player along with the likes of MongoDB and Elasticsearch if they could have gotten additional funding or focused more on business development. Note: both MongoDB and Elasticsearch are now hugely successful public companies. - Changefeeds were so useful and still to this day not really matched in quality. - Official client libraries were very high quality. I mainly used Node.js. - Performance (reads and writes) was impressive. - Setting up a highly available cluster with sharding was incredibly easy with a few clicks and types in the aforementioned web U/I. - Their web U/I was the best to ship with a database at the time. I still wear my RethinkDB shirt around, and it was a pleasure meeting one of the founders Michael Glukhovsky in San Francisco when they were still moving and grooving. The best technology and product doesn't always win.

wishinghand 6y ago
I liked the RethinkDB API better too. Seemed more intuitive and you could do something like joins in it too.
- dkersten 6y ago
  I loved the API. It made it very clear and easy to think about how my data is being accessed, how my indexes are used etc. I miss working with rethinkdb :(
WrtCdEvrydy 6y ago
Honestly, as the person who is ending up having to do the RethinkDB migration... it's the lack of an AWS hosted solution that killed it for us. Even the import is a great experience and moving to MongoDB wasn't too bad (after a bit of cleanup)
- nodesocket 6y ago
  Interesting, RethinkDB was really easy to setup. Three EC2 instances (cluster), install their apt repo, and install. There were a few config options[1], but really minimal and clean. [1] https://rethinkdb.com/docs/config-file/ https://rethinkdb.com/docs/config-file/