Well let me be the first to say that I think that is an absolutely fucking crazy valuation and that MongoDB are either nuts or disingenuous for signing up for it.
I would be astounded - astounded - if MongoDB generate even a tenth of that, just in revenue, ever.
One point two billion dollars. You have got to be kidding me. You have got to be fucking kidding me.
I hate to be That Guy, but I think this demands a bit more rigor. $1.2B is certainly a big number, but let's unpack what it means. Do you think it's impossible that MongoDB gets to $100M of net income? For a company that sells to the enterprise and whose product has significant adoption, that definitely doesn't sound implausible to me.
Given their financials and growth figures, how would you value MongoDB?
> I don't know. I haven't seen these financials. But it's a frigging database, and not a particularly good one. A billion dollars!?
Salesforce is a frigging CRM tool; SAP is a frigging ERP system; Oracle is a frigging database. And not particularly good ones at that, in the estimation of many of their users. Their market caps are $30 billion, $90 billion, and $150 billion, respectively.
I'm disappointed that yours is the top-voted comment. We can do better than this.
It's really not. Oracle has an enormous middleware portfolio, and plenty of other niches to boot. And, to be honest, much as it may be unfriendly, it's a pretty good database.
Yeah, I was being hyperbolic to try to make the point -- you can dismiss anything as merely a frigging X. You're absolutely right with regard to Oracle.
(Tangent: for anyone interested in Oracle's history/business, or just enterprise software in general, I highly recommend http://www.amazon.com/dp/0743225058)
I agree with you: at one point in time, Oracle probably was worth $1.2 billion. For all we know, MongoDB could grow into a company that spawns a lot of NoSQL middleware whatevers.
You're a stripe cofounder and you seriously can't see the difference between Salesforce, SAP, Oracle and a minor OSS DB?
Like all of the others charge for everything they do, have massive market penetration and one of them's fairly small can't charge for much? The OSS DB one?
Of course there's a difference (as reflected by MongoDB's relatively tiny valuation). The question is how likely it is that they can expand significantly from their current position. The trajectories of Salesforce, Oracle, and SAP — all of whom had similarly inauspicious beginnings — suggest that it's at least possible.
Not really, they do a whole lot more than that, especially in the SDK land, I hear they even have their own IDE for coding the Salesforce way.
> SAP is a frigging ERP system
Another one of those companies that has its hand in a lot of cookie jars, for example, they sell HANA (http://www.saphana.com/welcome), which is a very fast in-memory analytical database (SQL).
> Oracle is a frigging database
Oracle database is actually just a small part of Oracle these days, look at their Sun aquisition. I mean, Oracle even has their own flavor of RHEL now.
Back then, when they were the age 10gen/MongoDB is now, nobody valued those companies at (the appropriately adjusted equivalent of) 1.2 billion, because there was no clue they would be the winners.
All investors then were just overly cautious? Or perhaps there are now others ways to make money off of a company, not tied to the companies actual success and the value it adds to the economy?
> Back then, when they were the age 10gen/MongoDB is now, nobody valued those companies at (the appropriately adjusted equivalent of) 1.2 billion, because there was no clue they would be the winners.
Actually, MongoDB (formerly 10gen) is 6 years old. After 6 years, Salesforce's market cap was around $3 billion. (They IPO'd after 5 years.)
A market cap after n years is something different from a valuation derived from venture capital raised in prior years. Such a difference is precisely what makes for a good investment.
Salesforce revenue in the year of their IPO: $96M. IPO: $110M
> nobody valued those companies at (the appropriately adjusted equivalent of) 1.2 billion
One counterpoint. My friend worked at a university. This was back in the era of punch-cards. Oracle came in with their relational database sales pitch (they were basically a very small sales team). His manager (who managed the punch-carders) saw the huge potential that everyone else did not (e.g. 'never going to happen'). Bought Oracle stock right when it went public (mid-80s). Kept on buying it. Retired in her mid 40s. Now lives on her own farm, tending her own sheep (not sure if it was sheep or some other livestock), in the country.
I think your reaction is mostly an emotional speculation based on your dislike of their technology. As you pointed out yourself, we do not know the financials, their adoption rate numbers or other relevant facts to make a sound judgement on the valuation.
I absolutely would buy the stock if I had insight into the relevant information and liked what I saw.
MongoDB is not a particularly good database. But it is a pretty good in-memory cache that can persist to disk, which is a valuable technical niche. It's a small change in perspective (that is betrayed by their marketing) but has a huge impact on expectations, use and value.
No one's arguing that disk paging is high-performance. In fact, MongoDB themselves explicitly recommend that you keep your working set size below physical memory size.
> But it is a pretty good in-memory cache that can persist to disk, which is a valuable technical niche
It's not a niche at all. Those are standard OS primitives.
MongoDB arrived in the gap between MySQL sucking and SSDs becoming common enough that in-memory performance wasn't essential to get simple workloads to go.
MongoDB has quite poor in-memory performance due to its simplistic locking strategy. I personally think MongoDB only had the best marketing of any NoSQL database.
Yeah, memory-mapped files and journaling are standard OS primitives. I would say auto-sharding, replication, indexing, and complex schema-less querying are not.
In my experience, MongoDB arrived with NoSQL/BigTable to fill a different set of needs than RDBMS's. Relational databases are great but not all applications need full ACID or transactions. Sometimes applications require greater data modeling flexibility. Other times, pain-free scaling/distribution are important.
MySQL is great when those features are required, but even when you put SSDs under MySQL, it's still MySQL.
> I would say auto-sharding, replication, indexing, and complex schema-less querying are not.
Agreed; that was part of my point. Distributed KV stores are a genuine novelty over classic RDBMSes and open an important line of attack for some classes of problems.
> Relational databases are great but not all applications need full ACID or transactions.
Also agreed. As a relational bigot, however, I only begrudgingly give up those guarantees. My point about MongoDB striking at a very particular moment is important: if SSDs had been widespread in 2005, I believe NoSQL alternatives simply would not have anything like the momentum they do now. Very fast random access is a seismic shift in the algo-economics of database systems.
> even when you put SSDs under MySQL, it's still MySQL.
One of my pet peeves is that many people take the limits of MySQL for the limits of RDBMSes. It's a bit like taking the limits of small cars as the limits of all wheeled vehicles.
It so happens that I am working a project where the central model is a graph; so even an arch relational pom-pom waver like me is considering picking a NoSQL solution for it.
Cheers. And didn't mean to trigger a pet peeve, I was just continuing the example. The point was more "even when you put SSDs under an RDBMS, it's still an RDBMS".
Sorry, I guess, that you haven't heard of teams caching denormalized data in MongoDB...
MongoDB uses memory-mapped files across all available memory to manage data, it sacrifices ACID for speed, and its capped collections sacrifice undefined size for more speed. Its client drivers originally defaulted to fire-and-forget semantics, emphasizing its performance-oriented design. Such performance orientation is suitable for cache or cache-like needs. The general point is that its place in a system is different than that of the typical "database", whether it's SQL/RDBMS, ACID-compliant, or even document.
I'm fully aware of the MongoDB's trough of disillusionment status in the community hype cycle. 10gen brought this on by setting unrealistic expectations early on, through poor documentation and marketing. Calling it a database, a term laden in the mind of the professional developer with expectations of ACID compliance and proprietary languages, was a shortcut that ignored its atypical performance-first roots, and all of the trade-offs that followed from that. I've read more comments from people with a lack or faulty understanding of MongoDB to surmise that it's stalled in the trough because the name confuses developers. "In-memory cache with persistence" is a also shortcut, but one that is a little more circuitous and strikes a better balance.
Depending on your needs, mongo has a much nicer interface than redis... Not to mention supporting indexing in the DB instead of having to DIY your own... I used it at a site that did mostly classified listings, and the performance was a lot better than the SQL RDBMS that was being used for search/display.
Yes, I agree. But regarding my comment, the use case was caching with persistence. Redis has some persistence options (pure snapshot or pure journal), but they just aren't its primary use case and aren't nearly as mature or performant as MongoDB's memory-mapped filing. Also Redis is key-value so requires manual indexing, i.e. much more up-front developer effort.
MongoDB is at a scale community-wise where they are growing by leaps and bounds as MongoDB ends up in many places where MySQL used to rule and for many newer applications where the relational and transaction benefits of MySQL are unnecessary. You can find mature MongoDB bindings for everything and now assume that they are mature for pretty much every community you care about. When people come to programming for the first time, many are likely to now learn MongoDB as their first DB and not MySQL. With all this in mind, MongoDB is now basically a large snowball picking up lots of small wins everywhere because of ubiquity and gaining mass. MongoDB is the second major open source DB win since MySQL.
Given conformity, social proof, product awareness, large enough community to bet your non-tech business on it, do you doubt that it can't grow a bunch over the next 5+ years? It might be dead to you, but it's the next big thing to the rest of the world who are not as enlightened as we.
I don't believe there is any law that says they can't make anything other than a database. Perhaps they have plans to expand to other areas. Without seeing their finances, and knowing their future plans and the capabilities of the company as a whole, perhaps your judging the book by its cover :)
The issue here is that it does not matter if you like the current state of the product. The vision here is about the potential of the company. If they need to improve the product, hire/fire people to be there, they will (assuming competence).
I think it’s a crazy amount, but not necessarily wrong.
Mongo is the most popular NoSQL db
The interweb of the last 5-6 years created a large demand for JavaScript developers; this db (and or NodeJS) allows them to get into DB programming. Now that I think about that its like Windows did for OSes or Word for typing or HTML for web. So the growth potential is pretty large.
I think the best deal on a biz like this they can sign support contracts with an infinite number of customers to support their product, saving the customers money when shit breaks. That alone is a few million a year.
More importantly, the number is utterly and completely meaningless without the rest of the term sheet.
To be extreme, think of the difference between this investment as all common stock, versus this investment as participating preferred with 3x liquidation preferences.
I've seen companies trade liquidation preferences for higher valuations before, because they wanted to pretend a down round wasn't, or because they wanted to feign a greater level of success than had been earned. It wouldn't be unprecedented, particularly from a marketing-savvy company like Mongo that knows a 3 comma valuation would help close deals.
As an engineer directly involved in a company working on one of the biggest mongodb deployments, i also believe that this is crazy because the technology truly sucks outside of a very narrow use case (prototyping, no shard).
However they market it so much and they accept very flexible deals with enterprises, in combination with the easy-to-bootstrap for the VP/Manager/CTO, they can probably sell a lot of it.
They offer a deeply discounted option for startups and once you have lock-in (ie. running sharded, basically) and become dependent on the support, they increase the cost by 10x.
Well here's a thought. Don't become dependant on support. EVERY company who sells to enterprises makes their revenue from support. It's been this way for decades.
So if you are unhappy paying the money then invest in dedicated people.
Unlike something like Oracle that has been around for decades, at this point the admins I have are probably some of the most experienced MongoDB admins there are.
I, myself, have given several talks at MongoDB groups and without exception have been the most expert user in attendance. The only people who know more about MongoDB at this point work for 10gen.
The investors are putting up capital based on what they think Mongo will be worth at some future date after they have used the new capital to fuel growth. It's a bet, not an accounting exercise, and the bet is based on what might happen five or more years down the road.
The valuation is really irrelevant because it is a side effect of the negotiations between a syndicate with $150 million to invest and a company looking to raise money.
If the investors had negotiated less successfully, the valuation would be higher. If the company had been less successful, the valuation would have been lower.
But in either of those scenarios there would be little difference in their returns if Mongo goes bust, and little difference if they become Oracle sized in the next ten years.
I'd agree. Open source businesses have never been able to extract the value that closed source business can. Imagine if Oracle made their database open source; a dozen repackages would pop up, and Oracle's revenue would drop to a fraction of its former level.
Redhat is the perfect example. Compare their market cap. to OS vendors which are closed source: VMWare, Microsoft, and Apple. It's a pittance. Profit is only $150M a year depite the dominance of Linux in the server market. Oracle itself is valued at $150 billion. And for every Redhat, there's a Mandriva or a VA Linux.
The problem with selling service and support is that you have no incentive to make the product better or easier to use, and every incentive to make it usable only by experts, with a support contract. It's a bad business all around. And if the product is open source, it's easy enough to not pay for even if a need for support is baked into the product.
Open source can be a business. It's a viable strategy if you need a differentiator to compete with more established competitors, and the total addressable market you're looking to disrupt is ginormous. However, it's not a particularly good one in relative terms. The revenue generated per dollar of R&D is so small that it's difficult to fund innovation.
I think the second paragraph highlights the reason:
yes, open source companies make much less money than closed source alternatives, but in some markets closed source cannot compete with the OS equivalent -- e.g. most servers run on open source operating systems.
Is MongoDB going to fix their scalability, performance, JOIN, and data type support problems with the money? Seems like a bad investment to me since a lot of developers are starting to move away from it because of those problems and others.
MongoDB accounted for ~90% of my startup's downtime in its first year of existence. We switched away to MYSQL and suddenly scalability concerns retreated into the future.
You're right. It's easy to compile, configure, and start on a dev VPS. It's easy to fill with data and easy to query.
This is the sweet spot: when MongoDB is on a dev VPS and you're building a small product around it. Most devs don't have to worry about the next step.
Then you push everything live. If you're lucky enough to get any real traffic, everything other than 99% read crumbles. You scramble to shard but realize that sharding just doesn't work well, and is incredibly complicated to set up.
Then you start losing data...because the drivers are programmed to not fucking check if the data you sent was actually written (yes, I know, this is fixed). Ok, you set your driver on your flopping app to validate writes, and BAM there goes 80% of the write performance 10gen promised you.
The solution? Just add more shards!! Ok, so now I have 4 shards, each with 3 repsets + 3 config servers. 4 * 3 + 3 = 15. Fifteen servers to handle what one MySQL server could do in its sleep.
Conclusion: MongoDB is terrific as a write-only, developer friendly database that you will never have to scale, ever.
I wish I could upvote this comment more. I have to run over a hundred instances of MongoDB to equal the performance I could get from ten Postgres boxes, but now we have such massive lock-in on MongoDB we can't easily refactor.
The main issue is it being a JSON document store, and our application being designed around that and using the very specific MongoDB queries that involves.
Any wrapper would likely be worse than just keeping MongoDB.
We have the exact same issues with Mongo-specific queries. Even worse, our indexing regime (because we store relational data in Mongo) demands that we stick with Mongo 1.8, so all the comparative goodness of 2.x is lost.
And just this week, it was determined that there won't be any migration from Mongo to something-SQL in the near future, because it'd be too risky to attempt to translate a schema that's half foreign keys, half embedded JSON.
Can you point me to an article that explains why you would want JOINs in a NoSQL database to begin with? I thought the entire point was to denormalize your data. I keep seeing this point brought up, but it reads to me like a misguided complaint stemming from misunderstanding how to apply the tech.
The rethinkdb guys think it's important and have joins in their nosql product. Everytime I try nosql first thing I miss is the ability to query as the need arises without a refactor.
Using hierarchical data structures takes care of the most common use case of JOIN (i.e. "SELECT * FROM a, b, c"). This is a win for MongoDB. However there are times when you want to JOIN multiple hierarchical data structures [1]. Or use a different type of JOIN.
Actually, if you speak to them, they do claim that. Then they backtrack when you call them on it, but I've heard guys from 10gen as they were known then claim their product was a drop-in replacement for Oracle.
The entire point is to go fast; denormalization is a tool, not an end in itself. If, hypothetically (ahem), a database could scale and support joins, why not?
I'm pretty sure their download numbers say otherwise. One or two HN threads complaining about MongoDB every month are not a good indicator for their future success.
Yeah. FWIW, working at $BIGCORP, I'm starting to hear buzz around Mongo from quite a few not-very-technical people. I'm pretty negative on Mongo as a technology, but there's no doubt that it's generated a lot of attention.
In the short term it's probably inversely proportional: more 'complaints' means more people on the platform (or at least experimenting with the platform). In the long term we're all dead anyway.
He could also be using it the wrong way. Although MongoDB has faults, most of them are well known and developers are warned. MongoDB is far from being perfect, but the most common reason people hate on MongoDB is because they did things the wrong way or for the wrong reasons.
Automatic timezone conversion and the ability to add and subtract dates without first dropping to your 64-bit into. Think DATE_SUB(date time, INTERVAL 1 HOUR) from MySQL for instance.
The only explanation that ever made sense to me for that transaction was that it was to make them more attractive to their potential purchasers - MySQL was a very strange acquisition choice for Sun but for Oracle and IBM not so much.
... And then Monty and his team all quit, so what Sun actually got for a billion of their shareholder's dollars was the domain name mysql.com. One of the stupidest business decisions of all time.
Imagine what SUN could have built, if they had $1 billion in cash to spent on a Database. Stupid managers wouldn't let them, but they spent $1 billion on a hyped DB with questionable quality.
I always thought of the MySQL purchase as a last desperate attempt to get their geek mojo back. Not something that they could have done with an in house solution (quickly).
It still didn't work, but I don't think they were just trying to buy a database.
Sure, but investors in this round would _lose_ almost 20% if MongoDB got bought for $1B. Now, if it was EMC, CRM, Red Hat, and Intel making small investments in order to have some influence of the strategic direction of the company, that would make sense. But Sequoia? They must have a case for this making better than market returns over a multi-year window. I am skeptical, but I guess I'll have to revaluate...
If a trifle of a service like Instagram can get sold at 1 billion a legitimate piece of technology infrastructure valued at $1.2 seems reasonable to me.
Edit: corrected Instagram sale price from 2 to 1 billion, thanks Elliott
valuation of a social network = <# of users> * <$ value/user>
valuation of infrastructure = <# of deployments> * <margin/deployment>
The problem is that we cannot get an accurate estimate for the total value of a social network. We can usually get an accurate count of the number of users, and can even decently predict the number of potential users. However, when it comes to the value per user we have no idea what that number is because the avenues of monitization are so murky. Can instagram get just as much money per user as facebook? How about compared to Flickr users? How about SnapChat? Can we get a reasonable predict which social networks are fads and which are here to stay? To me, the value of a social network is much too foggy to reasonably predict.
The valuation of an infrastructure company is much easier to predict - it's a matter of price setting. If you are charging $100k for a product, and every fortune 500 company needs your product at that price, you can expect to be worth about $500M.
I don't really disagree with anything you say. But I think keeping longevity in perspective is important as well. Instagram is (mostly) at the mercy of fickle tweens and 20 somethings. If Mongo has a good management team they could be in the game long after Instagram becomes a shadow of it's former self, if you're selling to Fortune 500s odds are you aren't selling to them only once.
I dunno. It's a real business with real revenues, and tons of lock in. ORCL is worth $150B. It seems to me anyone who can steal marketshare from them could be worth at least 1% of that amount.
"This market is $XX billion, we only need to take 1% and we'll be rich" is a common startup fallacy. Stealing customers from Oracle is no easy endeavor.
That's very true, but Mongo has both a different product and dramatically different price point which should at least give them a fighting chance. You can't take on Oracle with a similar product that sells for 10% cheaper. With that statement, I'm really just parroting some of the tenets of the Blue Ocean strategy, but for the most part that book just makes sense and has validated what I've seen in competitive situations in the various industries I've worked in.
Oracle sold a product that was absolutely essential to pretty much every major business: there isn't really a good alternative to a transactional relational database running on middle-to-high-end hardware for a lot of companies. Selling something business-critical to customers with deep pockets is a pretty good business strategy. And they only had a couple of direct competitors in that space.
Well they've not got $1.2bn, they've got $150 million. There is nothing to say that they will be able to float or get bought at a similar valuation.
I can't see any of the investing arguments for MongoDB that even Facebook had. The whole space is full of competition for starters.
That's what I meant - I was congratulating them on getting the $1.2bn valuation. Agreed that there is a lot of competition and little certainty out there, though.
Look clearly you have zero understanding of how enterprises work. And given you have added Hazelcast which is a distributed in-memory solution in there shows you have a poor understanding of technology as well.
It is all about support. Big companies have operations teams who manage infrastructure and deployments. They aren't experts in databases and so want to be able to ring someone who can help them when the times get tough. 10gen understands this and have a great support story to talk about hence their popularity. Most OSS don't.
a simple fact that you get defensive and personal reveals that you are not happy with your confidence level. but that's ok, as you get more mature, and acquire a certain perception depth (and I wish you do), you'll prefer being constructive vs. angry.
I didn't mean to hurt your feelings. Hazelcast solves similar problem that all of the valuations in the list: "storing and retrieving data". By the way, "file system" does it too (let's valuate it as well @ $3.6B).
As far as "enterprise support" in case of Mongo, it's like running a political campaign: nobody really knows "who" is inside, until "he" gets elected, and when "he" does, the "support" needs to make sure reality stays hidden, by white (and not so white) lies. And yes, MongoDB is great at "support", most OSS aren't.
Lighten up. The submitter identified exactly the line and commit that enabled crashing all mongo deployments with a 16-byte post (I presume, from the report). Considering the circumstances, I congratulate the submitter on being so whimsical.
if (strcmp(buffer + position + 5, "$ref") == 0) { / DBRef */
That video is a bit unfair. I went to the MongoDB conference in NYC this year. None of the 10gen engineers made such silver bullet claims. They strengthened again and again that MongoDB is with significant limitations and scaling it requires a lot of effort and creativity from the client developer side.
That being said, I do wish they can use this investment to do more feature development than marketing.
...but you can be sure that it's going to be posted every time MongoDB comes up. Somehow, people will vote it up as if it's still funny or adds something to the discussion.
I have been using MongoDB every once in a while and I think it is great. The C# driver has linq support which increases productivity to the roof. However, the feature I miss the most while using MongoDB is multi document transaction support. Their site provides a workaround[1] that from my point of view is not worth implementing. Instead I prefer to switch back to traditional SQL databases in those situations.
Slightly off topic, but at what point does "big data" just become data?
According to wikipedia (which is in line with how I think about big data) "Big data is the term for a collection of data sets so large and complex that it becomes difficult to process using on-hand database management tools or traditional data processing applications. "
However, as "big data" becomes more mainstream and more tools/services exist to accommodate data at the peta/exobyte scale does that whole definition stop being relevant for kinds of data we're talking about?
Working in the risk analytics space, "Big Data" seems to be marketing speak for "you can dump all sorts of loosely structured data into this big bucket and our tools will help you find meaningful trends in it." I've yet to see an installation approaching anything near 300GB, so I think of big data as the new sexier label to put on ad hoc data mining applications.
But if it is for running ad hoc data mining on relatively small amounts of data, wouldn't a traditional SQL database do the job just as well? Especially with with features like the JSON support in PostgreSQL.
Yes, you are perfectly correct. But a lot of people are paid a lot of money for reinventing the wheel every few years, so expect your words to fall on deaf ears.
> "Big Data" seems to be marketing speak for "you can dump all sorts of loosely structured data into this big bucket and our tools will help you find meaningful trends in it."
My company actually bought some "big data"-machinery plus consulting and they actually delivered their hardware in a Very Large case. Truly one of those '90s dual big towers. I thought that was pretty funny, considering they put less data in it than fits on a $200 hard drive.
I actually first heard the term used in what has turned out be to be a very unusual sense. "Big Data" is like "Big Oil" - it's a term for industries that get their economic clout from the value of their data. Google, for instance, is "Big Data" because it's able to offer the advertising platforms and spam filtering services that it does because of the data it's extracting value from.
CmonDev put it nicely. Buzzword. Same when you hear, most of the time, how someone is leveraging Hadoop for whatever.
There are various definitions of what is big data. I like to think of it as whenever the only way to deal with your data is by doing full table scans, then we're in same domain of thinking of big data.
I wonder to what extent the AGPL license actually facilitates the creation of a commercial business based on the software; large online service customers who would be willing to use even GPL software without paying anybody for it might be more likely to opt to negotiate a commercial license for AGPL code.
If that is the case, though, and their revenue model is based on providing non-AGPL access to MongoDB, doesn't that rather put MongoDB in the position of commercially exploiting the work of developers who contribute their code under the expectation that it will be freely shared under AGPL?
> doesn't that rather put MongoDB in the position of commercially exploiting the work of developers who contribute their code under the expectation that it will be freely shared under AGPL?
While the MongoDB product is open source and licensed under the AGPL, they very rarely accept outside contributions. A vast majority of the product was built by 10gen/MongoDB, so this is less of an issue than it would be for something like Postgres.
Which seems like further evidence that the use of AGPL is somewhat disingenuous - more a poison-pill than a genuine attempt to embrace free software principles. If I use MongoDB, and modify it to suit my needs, I have to make my changes available to anyone who consumes a service I back with my modified MongoDB. MongoDB Inc., presumably by virtue of having licensing agreements in place with all the copyright holders whose code is in their core distribution of the product, have the ability not to do that. They could, however, examine my improvements and do a cleanroom reimplementation of them.
The real risk to them is that a vastly improved fork of MongoDB is built up by contributors who don't license over their contributions to MongoDB Inc., preventing their incorporation into commercial licensed versions...
The GPLs are meant to be poison pills. That's what they are for. Mongo's use of the license this way is standard, then in addition they allow you to buy the antidote.
People giving out code for free is poisonous? Here is someone people saying: "Hey, wrote some nice software. Here. You want it? Take it. We like it. It's Free.".
Now if you want to take that software and give it to someone else, they ask you to not go around the hide where you got it, what changes you made to it, and not sue people for patents over that software.
Its a polite, if backed up statement, that people can't go around using other people software and then be exploitative about it. Play nice, or do not play at all. Is it really your view that doing so is poisonous?
> The real risk to them is that a vastly improved fork of MongoDB is built up by contributors who don't license over their contributions to MongoDB Inc., preventing their incorporation into commercial licensed versions...
Whenever I see something like this, I can't help but think this is just a business deal. Nothing to do with technology. Rich business men are going to get richer because they can get away with over-valuing technology and tricking their non-tech savy investors into thinking this will make them a buttload. Some sort of quasi-pyramid scheme.
It's a common technique to serialize arbitrary data into blob fields in SQL databases--I've seen it for years. Usually, it is considered an anti-pattern. Postgres 9.1 doesn't do much other than verify the JSON data is valid JSON and then stores it unchanged, though successive versions are adding more first-class JSON support.
No, they lock the entire database for every write.
"MongoDB uses a readers-writer [1] lock that allows concurrent reads access to a database but gives exclusive access to a single write operation."
"Beginning with version 2.2, MongoDB implements locks on a per-database basis for most read and write operations. Some global operations, typically short lived operations involving multiple databases, still require a global “instance” wide lock. Before 2.2, there is only one “global” lock per mongod instance."
It's a shame they didn't think about the name a bit longer. In the UK "Mongo" is a fairly disparaging term and I find it hard to pitch MongoDB to customers because of this.
This is, actually, a real concern. So many companies that want to make a foray into enterprise sales don't think carefully about things that (on the surface) seem inconsequential but are actually hurting your business.
It doesn't seem to be hurting them at all actually. Mong, mongo/mongodb are not the same word it seems either. So whoever would make that cognitive connection would be wrong anyway.
I hope you're not a consultant building web apps for non-technical clients, because if that's the case, I can't imagine the scenario in which it would be necessary to 'pitch MongoDB'.
I'm a Mongo customer. Their customer service is probably the best I've had from an Enterprise vendor in terms of response time and general quality.
Unfortunately, the product itself is so poor I am forced to get the support, and even then I've managed to stump their senior engineers quite a bit with my "impossible" problems.
Pick any company in the Fortune 500, then pick any technology you like and I bet it's in there somewhere. That's simply the nature of organizations with 100,000 employees in a dozen countries.
A month ago I was contacted by a recruiter about some engineering opportunity. I was surprised to know that MongoDB gives me the feeling of Tech company like G or FB. I always thought of MongoDB as kind of an open source product. I started to learn how it operate as a business. I think this is a sign that enterprise-targeted business are rising, and there will be more and more of this kind of start ups in the future.
We're replacing at least one collection with text files. That's half Mongo's fault, half our fault for using it to store the kind of info we're storing.
I don't think MongoDB should be replacing systems, it should rather be used as a data store for things that otherwise wouldn't be stored because of the high throughput needs, but aren't necessarily critical data.
I've worked at enterprise companies with MongoDB deployments.
It is replacing Oracle databases which everybody is sick of. And given that most companies aren't clustering it is pretty much a simple drop in and replace scenario.
I know they're hiring like crazy in their new office in Dublin. Big growth spurt, massive cash injection, interesting to see if they become the first big "enterprisey" NoSQL provider.
I'm moving away too (er, have already moved). I have chosen RethinkDB and am very happy with it so far.
I think the most important thing to me is that the Rethink guys haven't lied about the database's capabilities and limitations.
10gen did. Both in their marketing and in their sales pitch to us when I worked at Aol. Never once did anybody mention a global write lock when we were talking to them about a write-heavy application.
Not a fan of Mongo personally, but understand the context of what is happening in corporate IT. Slashing and commoditization. They look at the $10M line item for Oracle and say wait a minute.. The last section of the article was the most telling.. We replace the millions $ and staff with a $5000 server. Just like trading in your US employee for an offshore replacement at 1/5th the cost. They love that message.
Remember too, the quality of the tech is one factor (way down on the list) in decision making of what these companies buy.
As far as the tech, Relational DB is certainly not the problem and even if it was, Mongo wouldn't be the solution. Mongo's riding the wave of slash and burn, and Oracle has pissed on more than a few customers over the years, basically with the attitude.. "where you gonna go!" Any company gets a toe-hold in big companies like Mongo has gonna be looked on very favorably by Wall St right now..
Mongo will get bought for sure, the valuation is not that nuts.
Now we could see how deceptive sales technologies and media manipulations are leading to ridiculous valuations instead of any new technologies or even appropriate (for a persistent storage engine) design decisions.
Still enjoying table-level locking on writes and lack of atomic writes in so-called transactions at $1,2B valuation?)
The same story as it was of MySQL prior to stabilized InnoDB (5.1.x) an extremely popular crap with table-level locks, silent data conversions and millions of ignorant 'satisfied customers'.
By the same logic PHP must be valued at one trillion - millions of satisfied cheap coders, and, you know, Facebook was written in it.)
If you having issues managing or scaling MongoDB you need to use a service like MongoDirector.com - make its really easy to deploy and scale shards (even in your own cloud account)
This is crazy. If I had known that I could gin up money for a crappy database I would have written one. This seems unfair, but we'll be joking about this in 10-15 years.
The 2nd Edition of the MongoDB: The Definitive Guide from O'Reilly is one I can recommend (full disclosure: I was a technical reviewer on that edition). http://shop.oreilly.com/product/0636920028031.do
Finally, there are free MongoDB courses available at http://education.mongodb.com in various flavors of programming language, as well as an ops/DBA focused course.
Best MongoDB training I had was to be at a company where they throw it into production, it crashed almost every day and then we got 10Gen to train us on what was going on. I got experience and wisdom all in a very short time.
I would be astounded - astounded - if MongoDB generate even a tenth of that, just in revenue, ever.
One point two billion dollars. You have got to be kidding me. You have got to be fucking kidding me.