They've made their share of mistakes, but they've stuck it out and have definitely improved their product over the years. I wish them all the best for their IPO. What would be really good to see As a measure of their business health is an indication of how their cloud business is doing with respect to their enterprise sales business. A healthy cloud business would signal less volatility in the face of high revenue garnered from fickle enterprise sales relationships that have been their bread and butter until the past couple years.
Reliability and implementation ideas aside, MongoDB popularized document stores and document stores can sometimes be a good thing (even if there's usually little to no reason to prefer them to plain SQL databases for most applications). So they deserve credit there.
Agreed; though the way they did their marketing early on the message they conveyed was that document databases were here to replace RDBMSs. It was extremely dishonest.
> early on the message they conveyed was that document databases were here to replace RDBMSs.
The CTO still thinks so. Quote[0]: "MongoDB's CTO disagrees with this statement arguing that nearly 90% of database installations today would benefit from being replaced with MongoDB"
To be more fair to them, it was just them and the "everyone" you're referring to was a result of a fantastic blatant + guerilla marketing campaign. Or maybe I should say a MEAN success? :)
It may seem like that from a certain perspective, but I remember drowning in the hype in 1992. It was going to be the next big thing: everything is going C++; you want objects; why would you store relational tables, when you want objects?; relational databases are just slow, clunky and complicate your code base. The company I was working at even tried it... very briefly :-) Unfortunately, I don't remember what we tried, but there were several around at the time. This stuff wasn't invented by MongoDB.
I haven't used MongoDB but I've listened to those who are pushing for it. Yes, that's unfortunate that mistakes have been made (especially when it comes to databases). But, better to find that mistake early on rather than later. And it speaks to the founders dedication to the project that they navigated the rough waters and saw it through.
It looks like the NoSQL movement was just a fad and plenty of startups got burned by it and some still stuck with this tech , writing inefficient workarounds for something that comes OTB with the regular SQL databases.
I worked with one of the largest ad publishing companies. They wanted to track data about every client served an ad. This generated over 1.2 Terabyte per hour of data when the MySQL master started to max out. We had the largest possible multiple core system. It was going to cost my client $30k to upgrade to SSD drives to get more out of MySQL. Also note we had to store this data on an expensive SAN in order to feed the data at a reasonable rate to MySQL or PostgreSQL.
I had just learned of MongoDB and went to school at 10gen for their sys admin class. I talked to the developer about storing the data in NoSQL using a small sharded cluster on a Friday. Monday morning he asked me to setup a MongoDB cluster. Tuesday we moved over from MySQL. They ended up using much smaller servers, got rid of the 3par and epsilon SAN's and saving tons of money.
My point is there are certain situations where NoSQL is still the answer unless you can cluster your SQL write server. I've moved on from working with Ad publishing clients but, I'm sure there are other places where SQL databases are not adequate.
NoSQL might be or, have been, a fad but, like any tool when used for the right job it works.
A production large scale ad. system system that was doing 1.2 TB per hour in writes, was migrated over from MySQL to MongoDB in roughly 24 hour window cool story Bro.
sounds like the wrong tool. what you are producing was probably logs data, which is immutable. There are far more efficient (storage, cpu) write-only stores.
Concider what a database does. It provides ACID properties and ability to query data. If all you need is writing data, the fastest you can do it write it directly to the disk, without the overhead a database comes with.
Using a loadbalancer in front of a farm of cheap logging machines, and aggreate the data you need for analysis to a suitable machine.
they'd still need to query their stuff, I guess, so you'd need to trow in there somewhere something to aggregate logs and get the metrics they're tracking out of it - which can totally be done in streaming, without the need of going trough the logs every time, for most metrics.
With that amount of data, streaming and only saving aggregated data is the only sane way. With 1.2TB/hour there is a limit to how much historical data that can be saved anyway, and we're talking about 30% utilization of a 10gbps network interface, so it's beyond using single machines for most usecases.
OTOH, if you're a consultant, and you can say 'hey guys I can save you 30k, my fee is only 15k', and you can do it in a week - I mean, there are weeks where I bill less than 15k...
The largest ad system ever, Google AdSense, used MySQL until circa 2014 when it moved to a completely custom DB backend, F1. F1 is also a SQL database, however.
Google does use bigtable and such where appropriate, but for anything more complex than dumb key/value you can't do much better than regular DBs. Some people think they can, but 99% of the time they're mistaken.
Startups got burnt by NoSQL because they wanted to use it for everything instead of thinking over use cases that fit. It's a good thing that this fad went away and now people would be more likely to educate themselves about relational vs. non-relational db before jumping into the fire pit.
There are a good reason to use NoSQL, for example to replace EAV. But definitely not a good use to do everything on NoSQL so most companies opted out for 2 database solution = SQL + NoSQL and did not get burned.
The thing however is that since Postgres released indexed BSON support (which is actually faster then MongoDB) there is absolutely no point in opting for 2 database solution and making things harder for no reason.
Or, get the best of both worlds. ToroDB puts a mongo wire protocol in front of Postgres, which outperforms mongo significantly on the same hardware. Plus, you can get read-only views on the Pg side to join with traditional relational data.
> Or, get the best of both worlds. ToroDB puts a mongo wire protocol in front of Postgres
Postgres alone is already the best of both worlds. With ToroDB, I am restricted to the MongoDB way of dealing with my data; with Postgres, I can mix SQL and NoSQL however I like, even in a single, simple SELECT query.
I have to agree that there was a lot of noise in the nosql world and a lot of people got carried away by the ease of use metric. I guess people were lured by the prospect of not having to write SQL joins.
That said I found nosql databases extremely helpful for storing and querying large unstructured data. Mostly because it was really hard to build relations and to store this data in tables. Think Wikipedia for instance. Since then my way of choosing databases is to try and model data into a relational db as much as possible and if that doesn't work out choose a nosql equivalent.
With Postgre you don't need to use a different database unless your workload is "bigdata". You can store relational data alongside unstructures json and query both.
Which amazes me how RethinkDB never eclipsed all of the other "nosql" offerings. A relational, realtime, document store. You get the benefits from both sides.
Depends on what you're doing. We've used it on at least one production product at work where it works fine and probably will not be replaced. (If it's not broken don't fix it TM)
We can thank it a rough Mozilla devs that long moved one, that WebSQL got stopped and is support in Webkit and Blink (100% mobile devices, 80% notebook), but not on Firefox. Instead this NoSQL IndexedDB was introduced. Let's get over NoSQL fad, and support SQL in web browser!
Both Hortonworks & Cloudera are the most similar recent IPOs. Hortonworks is below the offering price, Cloudera has been basically flat. And this is in the context of an insane bull market for tech stocks and the market in general.
So we will see how this turns out. It's been a couple years since they last raised funding so its possible they didn't really have another choice. Chances are if the numbers on the S-1 were truly great they wouldn't have done it confidentially.
Nutanix, Twilio are two recent ones (IPO'd in 2016). They both were great performers last year.
I don't have the time to dig up all the data and do a comparison of the correlation between returns on companies that used the confidentiality exception vs. companies that didn't, but it would certainly be an interesting analysis.
Are you sure Twilio or Nutanix didn't file confidentially before its S-1 was flipped public? I'm actually not sure if there's a way to tell, other than a leak.
It's worse than that, cloudera went public at a valuation below the price set during their last round of fundraising. Also, people are bullish on tech companies that are consumer tech related or are in the enterprise space serving industries not relating to tech directly. P/E ratios for companies like oracle, ibm and cisco aren't that high.
MongoDBs market is not exactly the same as the Hadoop vendors' although there are overlaps. One of the biggest driver of adoption for mongo are projects that start out as small, rapidly done prototypes and then grow large. It's really easy to start with and scale to decent amounts of data with mongodb.
It's not the same exact market but its essentially the same business model - build a community around an open source system and then upsell enterprise customers on support, consulting & services.
Big difference is in fact apparent right there in your original post: There are two (actually three plus more) vendors backing hadoop, an amorphous community based around an Apache foundation project that no commercial entity controls. This means the Hadoop ecosystem, while generating plenty of value, is not one that can be captured by a particular firm. Plus, the operational database market is ultimately far larger than the Hadoop ecosystem, and so taking a reasonable bite out of it means a materially different market. Finally, it's not just about control of the market, but the software license. Hadoop vendors have little defense of an Apache licensed stack, and face massive threats from new cloud offerings.
Good points. For what its worth there are other successful MongoDB hosting providers - mLab (originally MongoLab), compose (originally MongoHQ), and ObjectRocket - so they (MongoDB, Inc) don't have complete control over the ecosystem, despite the AGPL licensing. Well, they do have the market for support cornered, but long term the margins on that are much lower than DBaaS.
I think a larger issue for MongoDB (& Hortonworks/Cloudera/MapR) is Amazon/GCS/Microsoft hosted services that obsolete them for many use cases. MS already has Azure DocumentDB that supports ACID transactions and has a MongoDB compatible API.
Here is where I point out that MongoDB dominated write benchmarks when it first came out. And then everyone complained loudly that the benchmark was writing to PostgreSQL and flushing to disk while Mongo turned off safe writes so they'd do better on the benchmark. Once that was fixed, Mongo plummeted towards the bottom of the rankings.
The benchmark measures almost exclusively read performance, so that's not really a question.
Now the real question is why mongodb isn't faster than postgresql in this test. MongoDB gives so many guarantees up just to get more performance, and then looses to PostgreSQL? This is the worst trade deal in the history of trade deals.
well I wouldn't account that benchmark. Not for mongodb and especially not for PostgreSQL.
TechEmpower Benchmarks are mostly not really showcasing real world.
Just looking at their PostgreSQL config will highlight that. (Especially: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...)
And also most of the time their libraries/frameworks are outdated or not even configured correctly.
It shouldn't be taken as a reference in any way without additional benchmarking.
think it is a bad fit and a bad time for an IPO, their market just isnt big enough and their losing a lot of steam as of late.
most importantly in terms of numbers, there is nothing going for them. they arent exactly redhat level in terms of support, nor rackspace level for subscriptions, and nor snapchat level in terms of market reach.
this looks like some last effort cash out sort of deal to me. weird to say that its somewhat of a sad outcome for an once promising opensource company.
They recently passed a suite of jepsen tests that finally gives them legitimacy they needed (the latest server release has very good consistency now). MongoDB is in a good place from a technical position.
Passing the Jepsen tests mean they'd say they're addressing the larger part of that market, rather than document stores specifically.
(I still think MongoDB, the company, isn't particularly great for the usual reasons re their past behaviour, I'm just imagining what they'd tell their investors)
Did you consider that perhaps projection of growth is exactly what you'd do in the event of an IPO? Or that Google trends isn't a sensible heuristic for a valuation?
I've down-voted you not because I disagree fundamentally (although I don't rate MongoDB) but because you are dismantling an argument badly. I hope that isn't too rude.
it is exactly what you'd do in the event of an IPO. I just don't understand how investing tons of money in human capital could be considered a "cash out" as the person I was replying to put it. If anything, it's the opposite.
Google Trends indicates how many new projects look for a database. Database companies typically make money with existing projects (subscription fees or occasionally new versions).
I agree that MongoDB is considered for many new projects but they will have very low market share for existing enterprise projects (which is where the money is).
I know MomgoDB is not very favored in HN but if there is one thing Mongo taught us, is that a nice and simple API to access your data makes a world of difference.
Starting with the JOBS Act (in 2012), certain smaller companies under a revenue threshold were allowed to file their initial draft registration statements with the SEC confidentially. It was meant to encourage startups to go public and avoid the public eye while they negotiated their registration statements with the SEC. It all goes public before the IPO.
The leak builds up hype and investor curiosity about the IPO. It's like how visits by politicians to an area are 'leaked' so that the press is there to cover them.
You may be assuming that every employee of a company cares about the company's best interests. I find it unlikely that a janitor, intern, disgruntled employee, etc. would be unwilling to spill juicy details for a small fee or feeling of importance.
There's no reason a for profit company can't ship an open source project. :)
MongoDB is an open source project, and the MongoDB company is a for profit corporation that ships the database and sells support and services related to it.
Check out RethinkDB, a competing product which had exactly this happen earlier this year. I don't follow the project closely, but the Linux Foundation picked up stewardship and development appears to be continuing, if at a reduced pace.
MongoDB is pretty popular, so while it would certainly be disruptive in the short term for the sponsoring company to go out of business, continued community development is all but assured.
I think the reality is that many large OSS projects are corporate sponsored, either directly or via companies paying developers to work in the project.
In a case like MongoDB, if the company faced difficultly or even went out of business, the product would undoubtedly be affected.
But since it's a popular open source product that many companies depend on, it seems unlikely it would die. For some of the successful companies using MongoDB at scale, paying developers to work on the project could very well be cheaper than migrating to something else.
I think this is true for large open source projects generally. It's nice to at least have the option of taking the code into your own hands if the company or people developing it decide to stop for any reason.
Really? I thought the MongoDB fad had gone away, that common sense returned, and people either used proper document stores, or proper relational databases, or graph databases.
Could you be a little more specific as to what a proper document store is? Mongodb has impressed me after using it for two years in a highly concurrent and rapidly changing big data production system. It's not without its significant headaches, but I've yet to find a database that is.
I don't see why. SNAP hasn't really figured out how to make money and their features were easy to copy (and copy better) in Facebook's properties.
MongoDB is far longer established, has a large enterprise business and likely has a sizable cloud business. These are not "features" you slap onto another product and then simply have users come flooding to you. No, databases are pretty critical pieces of infrastructure.
As long as the business is solid this IPO should work out well, IMO.
I think it's easy to equate, because in our bubble we hear so much Mongo hype, but to the much larger world, they know as much about Mongo as they do Firebase or New Relic. Also, Mongo the technology has a different set of expectations than Mongo the publicly traded company.
