In our economy this is sadly an entirely valid route to making money but their mindshare is going to continue to collapse as the warts on their product show more and more.
So the admiration you have should probably be directed at the wool the marketers behind MongoDB managed to pull over your eyes.
It is extremely difficult to do good marketing and sales and they did it.
Solve a customer problem while building a healthy business... a success story in my book.
There is so much work to running a successful business, especially at that scale. Marketing, Sales, Implementation, Support, on top of G&A, and that's not even touching on HR and retaining employees in a competitive market.
There is a reason some people are known as the "business" guys, I think expertise in that area is underrated, especially among people who've only worked at smaller companies or startups.
Edit: Genuinely curious to know why I'm being downvoted. Care to elaborate on why you're downvoting?
There are plenty of reasons to write good quality code (it's more maintainable, moves faster, more secure, requires less resources, more fun, etc) but "because you won't be successful if you don't" really isn't one of them.
A good example is some of the comments that software folks make about the sales department.
They are different skillsets and people have varied abilities in each. The business aspect is not actually easy. It is also not always done well. The software end isn't always done well, either.
My guess would be that is why you were being downvoted. I notice a number of votes are emotional in nature. They aren't based on logic. I see some that are most easily explained as, "I don't want to know." The comment is factual, not confrontational, and topical. The vote is still negative.
Meh... I don't mind it when it happens to me. I have karma to spare and don't actually make comments for the points. I say what I feel needs to be said and try to stick mostly within the guidelines. (I do meander off topic sometimes.)
But, no... I don't comment for the points. I comment for the replies and thoughts. They are usually quite brilliant and insightful.
It's not like they were just a vendor of some other product. They actually spent money on the product, on evangelism (kind of marketing, but also kind of development), on so much.
Stripe's technical achievements at first were basically "a nice button" and a slightly friendlier risk model. Yet they are lauded (as they should be!). We can cut Mongo some slack given how we act about other companies.
To make such an assertion, you're going to have to provide evidence that the people using Mongo and it's services, are, in fact too stupid to know what's good for them, and that they are absolutely better off using something else.
Basically I'm in complete agreement with you, and feel this is a hard learned lesson.
That said, I do think they made a way of handling a data model pleasurable. Different paradigm++
Except that Mongo didn't find success through "simply being successfully marketed". So many people in this thread cannot seem to understand how to look at the business as a whole. Software devs are blasting the software for not being a mind-blowing piece of technology, while not understanding that it has its niche and - apparently - a good business strategy.
You cannot (typically) succeed by only having an amazing product. You also (typically) cannot succeed by dumping millions into sales and marketing for a truly garbage product. The product itself and the business behind it are both necessary elements for success.
There are a lot of developers in this thread trying very hard to appear smart by jumping on the "Mongo is a joke" bandwagon.
Imagine if everyone using MongoDB had to pay for it, you know, like most things in the world?
I suggest they are giving away their cake and picking up a few crumbs after the fact.
Builders don't typically give away homes to sell a few cabinets.
The "product" of a startup is a sustainable business model that can scale fast. The core technology may or may not be a key element part of that model.
So they solved a customer problem with interesting technology - regardless of arguments if it ACID compliant, or as good as <replace with whatever you think is "better">.
Where they sustainable at the beginning? No. Are they sustainable now and did they scale appropriately? Yes.
As a startup that went through it stages, they did it. This is not easy because it requires all the elements to work properly (market need, sales, marketing, engineering, operations, etc).
So what if RethinkDB/or_other has a feature that is better? Irrelevant.
Even better they did this ethically, which is more than I can say about other "startups" with insane funding and dubious and questionable strategies.
As much as I'd love this to be true, the #1 measure of success is if people even know you exist and #2 is if you solve enough of a customer's problems that it's worth using your product. MongoDB hit these two points hard right out of the gate and are now very successful because of it.
What Mongo did is implementing these features just well enough so they can put checkpoint in their marketing brochures.
When you actually start using it you learn that most of it is either performing slow, does not work correctly or once in a while corrupts your data.
Yes they hit these points hard, but only from marketing point of view. They are now universally hated by ops and developers because these people now have to deal with fallout.
RethinkDB actually is an example that database is something that's not good as a base for a startup[1], and the Open Source approach (like PostgrSQL) is more suitable.
MongoDB is example that you can base a startup on a database technology and succeed, if you can sleep well at night that your product can cause people to lose data.
[1] The reason RethinkDB failed was because they refused to provide half solutions like MongoDB, everyone expects startup to start making money, but building a reliable databases is not something that's easy and can't be done quickly.
MongoDB serviced one of my projects for 5 years without a single hitch. It did everything I wanted it to do, it did it well, it did it exactly as advertised (no more, no less), and it did it right when I needed it. It never stopped improving during those years, massively in some aspects. The company behind it only grew stronger during those years, and along with it, so did my confidence that my project wouldn't need to undergo re-engineering further down the line.
Seriously, as a professional software developer, what more do you want.
Secondly, it’s the ReQL. It’s not native but not JSON based either. A weird hybrid mix.
But it’s only my personal opinion based on my taste.
> A RethinkDB employee told me he thought I was their biggest user in terms of how hard I was pushing RethinkDB.
http://blog.sagemath.com/2017/02/09/rethinkdb-vs-postgres.ht...
Thats how most products succeed if you ask me.
Let me clarify a bit, I'm not saying that this tactic is invalid or inefficient within our current system, in fact this is a great way to land a good payday if you can pull it off. My point was more that MongoDB is going to implode when their performance shortfalls become visible to the wider populace, if that happens, of course. It's still possible they take the earnings from this IPO and dump heavy into R&D investment to make up the lost ground, but it's also very possible they take this payday and ride out the tech until it breaks down.
I actually chose it back in 2010 project and on paper MongoDB looked better than other databases. MongoDB name as they mentioned originates from Humongous Database giving false impression that it can scale well.
They get zero points for this.
It pretty much reads as "Retard"DB in Portuguese, Spanish, and IIRC German.
https://en.wiktionary.org/wiki/mongo
Interesting this isn't the case with English.
https://en.wiktionary.org/wiki/mong#English (Etymology 3)
It didn't do ACID, not even nearly, but it did other praiseworthy things, with "laser focus on four critical things: onboarding, usability, libraries and support" (https://www.nemil.com/mongo/2.html). Please don't be disparaging about any of those four.
http://scale-out-blog.blogspot.com/2011/05/introducing-mysql...
Don't put down 'easy'. It's incredibly hard to do well.
P.s., I'm DBMS guy and have lived and breathed Jim Grey-style transactional consistency for decades. I'm still impressed by what they did.
I’ve no idea to what extent this was true, or if it was whether it was their main marketing approach, but it might have been quite an effective strategy: talks at meetups are often 'trusted' to a greater extent than other ways of reaching devs & if you can find a new generation of devs who are just starting out and hook them on your product before they get the chance to explore other approaches then it could work. High cost of course (someone has to pay for all that time) but if it gets you a leg up on your competitors in a $billion business then that’s what the VC money is for...
However, when it comes to writing software that's meant to survive changes and versions the schema ends up providing a safety net that ensures you can ignore the data that exists and assume that the structure described by your schema is consistent. Data integrity is key to maintainability and those constraints are what keep your data clean.
Makes you wonder what other meetup/hackathon visible tech is really covert marketing...
I'm not clear on why you think this—software products with huge mindshare and an open contribution model, get their warts fixed, usually by programmers sponsored by corporations repackaging the software (Redhat and Canonical with Linux) or running the software in a SaaS model (Cloudant with CouchDB.)
- "You don't get it, Steve. That doesn't matter!"
Add MongoDB to the list. Its "good enough", and marketed well.
Downvoted for this. I haven't used docker much but I just did
> yum install docker-ce
and started the service. took me less than 2 mins.
You ran "yum install docker-ce" you were lucky that you knew the name of the package. I didn't know the name on Fedora, and looking here https://docs.docker.com/engine/installation/linux/docker-ce/... didn't help one bit. Indeed, that page doesn't include a line with "yum" in it at all!
Ive read a Bloomberg story on the IPO and saw there two hilarious sequences "MongoDB has 4,300 paying customers. MongoDB employs 820 people in 29 offices" - that does not compute (for me) so I started analyzing their financial report (btw funny is nobody in whole HN discussion quoted numbers from the report so far, but a lot of 'im buying their stock' talks here).
In the report, scroll to the bottom where they put some cream: they show for last year 91m rev from subscriptions plus 10m from services. While at the same time they show operating LOSS of 85 millions (due to cost, people, marketing, sales, services etc). Khem khem, I know they are growing (holy world) but no, that does not compute.
Of course it is just mine opinion, and looking on the IPO results, rather unpopular one :) but I will stand by it. Especially in next 3 years. Caveat emptor.
I will short them soon.
It seems like you’re trying to value the company in a manner that doesn’t make sense for this stage of a company, and you could lose a hell of a lot of money.
For the uninitiated in the stock market: you shouldn’t really be shorting anything, especially not growth stocks, and abso-freaking-lutely not immediately following an IPO.
Mongo don't have to be committing fraud, of course. They could be doing any number of actual business activities that make legitimate trades --- but trades optimised at revenue growth, not profitability.
The major metric for companies used to be profit growth. When companies were optimising for that, it was smart to look at revenue growth as a leading indicator. But Goodhart's law ruins everything: now companies know to optimise for revenue growth, and so its value as a metric is much diminished.
I had a look at their prospectus, which describes the bulk of their revenue as subscriptions. Subscriptions sound like good unit economics. It's instructive to compare their pitch to investors to the pitch they make their customers: http://s3.amazonaws.com/info-mongodb-com/TCO_MongoDB_vs._Ora...
When Mongo talk to their customers, they describe the license cost as $0 --- they fold that into support. That sounds more like a service.
In other words: customer fires $100k of staff, pays Mongo $80k in "subscription", Mongo hires $120k of staff, which they tally up as "customer success". There's no expense category for support in their prospectus, so clearly the support personnel are filed under "sales and marketing".
It's the same old story. They're just selling $1 bills for $0.80 a piece.
Note the downside is unlimited when you short via spread betting. Eg, there's no maximum value of a stock, so you might get proper f'd.
It is however..simple. Very simple. It's easy to reason about. It's easy to setup. For 90% of use cases it's very easy to administer.
It turns out the market for that type of data store. Something you can apt-get install and just start dropping data into is pretty massive. I've used MongoDB on a few occasions. Usually thinking I'm just using it to bootstrap a project, but three years later it's still running because it's just good enough to keep me from moving on to something else.
I think you hit the nail on the head -- for many programmers who were "coming of age" at that time Mongo was the easiest to experiment with and to get working.
I since turned to RethinkDB and sometimes just a classic SQL will do, but Mongo is really easy to get started with.
That was because it was heavily marketed, not because of timing.
> Mongo was the easiest to experiment with and to get working.
It really wasn't, it was the one they had heard about.
I think most of HN would feel this way about, say, Redis. And Redis isn't "highest scale" or "most durable" or "most available" either. (Though it is pretty reliable.)
It's interesting, then, to compare the general impression people here have to MongoDB to the one they have of Redis. To me, Mongo is a "why use it when Postgres is just as easy to install", while Redis is exactly what I'd think of "to bootstrap a project, but three years later it's still running."
Is it just the slightly-different pitched use-cases of "working store" (Redis) vs "persistent store" (Mongo)? Is it that Redis still has its uses even when you've got Postgres there beside it, whereas Mongo doesn't so much (at least since Postgres got JSON columns)?
...until it's not. Then it's really not.
I went back to PostgreSQL since. I probably needed a good one-on-one expert training with MongoDB, but I just found myself happier with RDBMS. You don't have to be strict normalization in RDBMS, just enough to make sense for your use cases.
One thing I really did like about MongoDB back then was storing blob (files). It was the best solution available without setting up S3. At the time there was a limitation with 4GB (??) but MongoDB worked for my use case anyway. That being said, please don't store files in any databases today. Use DB to store references to a real object storage like S3. When the DB crashed, you better hope no corruption.
But from my perspective, this is delusional. There is a lot that goes into DBA's experience that is not solved by the performance improvements in databases over the past decade. But there are more choices. 20-30 years ago, you would have been forced to write code on Oracle and you would have asked for help before deciding how to structure the data. Today, with more choices, you just read some online opinions, and jump on it without any internal resource to guide you.
Not saying the world of Oracle was great, but the young on this thread (me included) would benefit from respecting the experience of the old.
Yes, everyone wants "full stack" and so you have a bunch of people haphazardly adorning themselves with the "full stack" label.
For example, I used Mongo back in the early days. Was terrible. I will now never use it again. I don't care if it shoots lasers. It is dead to me.
Obviously the happy developer count is way more than the hate it for life count, so I am the odd man out here. Perhaps many users never actually had many GB of data or had to deal with the data loss side of things?
The high valuation could be an index of the number of failing products happily using the tech :)
If my boss tells me to use MongoDB tomorrow or live on the street despite my advice to the contrary, I will use MongoDB happily. I may look for a new job in my free time if using MongoDB makes me miserable, but I certainly won't be living on the street...
And quitting your job (as you now point out, but didn't originally) is much different from "choosing to be homeless".
That's a bit too dramatic.
Next time, just say "I'd rather quit than work with MongoDB again", and you won't have this problem.
Fair point... “I would quit rather than work with MongoDB again” is more accurate, but still encapsulates your point.
The point I was trying to make earlier and did in a way overly dramatic for you is that I’d never take a tech job again if it meant I had to use Mongo.
MongoDB is the best in class at how programmer-friendly it is. Its API is easy to work with. This is especially the case if you are using node and javascript.
Neither of those are true, however.
It is being used by Facebook, Metlife, Expedia, Sony, eBay, Adobe etc.
In what way isn't it ready for production use cases ?
Sony is a worldwide company with 127,000 employees, they alone probably use just about every database system around. So saying sony uses mongo isn't impressive, for all we know it was just a side project from an intern that has 100 documents, there is no context.
Well I have worked for a number of billion dollar companies who have run MongoDB so there is first hand evidence.
And how is that a paradigm shift? Non-relational, non-SQL databases have been around for a long, long time.
Your parent commenter doesn't like Mongo. So it's not production ready.
Eh I don't like Mongo because I've used it. IDK, it's been a few years since I've had to deal with mongo in a production environment. I don't miss it. I dislike that it's slow to get data to/from the javascript interpreter -- and that the solution was to work around it with the aggregation framework.
I don't like the unsafe defaults (data integrity, access control).
I don't like the magical, unreliable sharding that you have little to no control over.
Well, it's a success story due to marketing, smart marketing, clever marketing, and more marketing, not due to lots of technical merits.
And it was not the first document store to appear, just the most successful. For starters, CouchDB was previous to MongoDB.
We used replication on the native apps for offline mode, kept things simpler with online-only for our web app, and have had a very good time overall.
We are also using JSON schema for our CouchDB documents so we ensure we don't have all kinds of wild / wrong data showing up; if you had really hairy, unstructured data, I can see why a dynamic language might help with that bad situation, but for our use case, we were able to take advantage of the powerful replication built into CouchDB and get solid offline syncing for all of our native apps that also plays nicely with live updates in a web browser.
(Note: I used to be optimistic about NoSQL, but I was dismayed by the extremely low quality that NoSQL products started out at, and stayed at, for a very long time)
Ah yes, the "toss your data over the fence and hope for the best" paradigm.
Truly groundbreaking.
The MDB's market cap, i.e. it's valuation, is around $1.17 billion as of the time this article was written:
https://www.cnbc.com/2017/10/18/mongodb-prices-its-ipo-worth...
EDIT: Added 'billion'
Recently I read about Postgres 10 release. Almost all of the features of that are available in MongoDB too.
4 or 5 years ago, MongoDB was bad. But nowsaday the landscape was changed, and I would say MongoDB is quite decent to work with now. It's the easiest database to manage, compare with MySQl, PostgreSQL, ElasticSearch.
Undeniably, they did have their fuck-ups in the start, but I think they have done a good job fixing them.