Two weeks ago MongoDB, formerly known as 10gen, announced a massive $150M funding round said to be the largest in the history of databases lead by Fidelity, Altimeter, and Salesforce.com with participation from existing investors Intel, NEA, Red Hat, and Sequoia. This brings the total capital raised by MongoDB to $231M, making it the best-funded database / big data technology of all time.
What does this mean?
The two winners of the next-generation NoSQL database wars have been decided: MongoDB and Hadoop. The faster the runner-ups figure that out, the faster they can carve off sensible niches on the periphery of the market instead of running like decapitated chickens in the middle. [1]
The first reason I say this is because of the increasing returns (or, network effects) in platform markets. These effects are weak to non-existent in applications markets, but in core platform markets like databases, the rich invariably get richer. Why?
- The more people that use a database, the easier it is to find people to staff teams so the more likely you are to use it.
- The more people that use a database, the richer the community of people you can leverage to get help
- The more people that build applications atop a database, the less perceived risk there is in building a new application atop it.
- The more people that use a database, the more jobs there are around it, which attracts more people to learn how to use it.
- The more people that use a database, the cooler it is seen to be which in turn attracts more people to want to learn it.
- The more people that use a database, the more likely major universities are to teach how to use it in their computer science departments.
To see just how strong MongoDB has become in this regard, see here. My favorite analysis is the 451 Groups’ LinkedIn NoSQL skills analysis, below.
This is why betting on horizontal underdogs in core platform markets is rarely a good idea. At some point, best technology or not, a strong leader becomes the universal safe choice. Consider 1990 to about 2005 where the relational model was the chosen technology and the market a comfortable oligopoly ruled by Oracle, IBM, and Microsoft.
It’s taken 30+ years (and numerous prior failed attempts) to create a credible threat to the relational stasis, but the combination of three forces is proving to be a perfect storm:
- Open source business models which cut costs by a factor of 10
- Increasing amounts of data in unstructured data types which do not map well to the relational model.
- A change in hardware topology to from fewer/bigger computers to vast numbers of smaller ones.
While all technologies die slowly, the best days of relational databases are now clearly behind them. Kids graduating college today see SQL the way I saw COBOL when I graduated from Berkeley in 1985. Yes, COBOL was everywhere. Yes, you could easily get a job programming it. But it was not cool in any way whatsoever and it certainly was not the future. It was more of a “trade school” language than interesting computer science.
The second reason I say this is because of my experience at Ingres, one of the original relational database providers which — despite growing from ~$30M to ~$250M during my tenure from 1985 to 1992 — never realized that it had lost the market and needed a plan B strategy. In Ingres’s case (and with full 20/20 hindsight) there was a very viable plan B available: as the leader in query optimization, Ingres could have easily focused exclusively on data warehousing at its dawn and become the leader in that segment as opposed to a loser in the overall market. Yet, executives too often deny market reality, preferring to die in the name of “going big” as opposed to living (and prospering) in what could be seen as “going home.” Runner-up vendors should think hard about the lessons of Ingres.
The last reason I say this is because of what I see as a change in venture capital. In the 1980s and 1990s VCs used to fund categories and cage-fights. A new category would be identified, 5-10 companies would get created around it, each might raise $20-$30M in venture capital and then there would be one heck of a cage-fight for market leadership.
Today that seems less true. VCs seem to prefer funding companies to categories. (Does anyone know what category Box is in? Does anyone care about any other vendor in it?) Today, it seems that VCs fund fewer players, create fewer cage-fights, and prefer to invest much more, much later in a company that appears to be a clear winner.
This, so-called “momentum investing” itself helps to anoint winners because if Box can raise $309M, then it doesn’t really matter how smart the folks at WatchDox are or how clever their technology.
MongoDB is in this enviable position in the next-generation (open source) NoSQL database market. It has built a huge following, that huge following is attracting a huge-r (sorry) following. That cycle is attracting momentum investors who see MongoDB as the clear leader. Those investors give MongoDB $150M.
By my math, if entirely invested in sales [2], that money could fund hiring some 500 sales teams who could generate maybe $400M a year in incremental revenue. Which would in turn will attract more users. Which would make the community bigger. Which would de-risk using the system. Which would attract more users.
And, quoting Vonnegut, so it goes.
# # #
Disclaimer: I own shares in several of the companies mentioned herein as well as competitors who are not. See my FAQ for more.
[1] Because I try to avoid writing about MarkLogic, I should be clear that while one can (and I have) argued that MarkLogic is a NoSQL system, my thinking has evolved over time and I now put much more weight on the open-source test as described in the “perfect storm” paragraph above. Ergo, for the purposes of this post, I exclude MarkLogic entirely from the analysis because they are not in the open-source NoSQL market (despite the 451’s including them in their skills index). Regarding MarkLogic, I have no public opinion and I do not view MongoDB’s or Hadoop’s success as definitively meaning either anything either good or bad for them.
[2] Which, by the way, they have explicitly said they will not do. They have said, “the company will use these funds to further invest in the core MongoDB project as well as in MongoDB Management Service, a suite of tools and services to operate MongoDB at scale. In addition, MongoDB will extend its efforts in supporting its growing user base throughout the world.”
Even though I am very excited for my friends and former colleagues at MongoDB, I think it is premature to declare ‘game over’ in a broad market sense. While there is greater market recognition (and acceptance) of new data management technologies from vendors outside of the oligarchy of Oracle, IBM, and Microsoft, I do not think this is a winner take all market. There are use cases where a JSON, document-oriented database is a better fit than an in-memory, SQL-oriented solution (and vice versa). The key is understanding (and articulating) the specific use cases where your solution excels (and focusing on where the largest market opportunities exist).
I do not believe MongoDB should try to solve a zero-sum problem (or if they are even trying to).
You could have easily said the same prudent thing about relational in 1985. It’s only really good today at decision support queries on small volumes of data, particularly data that does not lend itself well to being mapped hierarchically. You should not use an RDBMS for transaction processing as hierarchical and network databases are already fantastic at doing that. You should not use them for central IT tasks in general which should be left to the mainframe. And hierarchical databases will be with us for the next 30 years!
All these statements would have been correct and prudent at the time. So while I don’t disagree with you, Ken, the fun part is thinking a bit further out and thinking about change. Back in 1985, it’s not that RDBMSs can’t do transactions today, it’s that the optimization to do them are well known and already implemented in the existing H/NDBMS technology and … one day RDBMS vendors can and should implement them, and it won’t be that hard.
But as a market entry strategy, yes, OLTP transactions would have been terrible. But we shouldn’t confuse entry-strategies with eventual, over decades, outcomes.
Put differently, I meet a startup that was putting a database of books and authors, a problem that is as relational as the day is long, in Cassandra. Why, I asked? “Because it can do the job and it’s what I know,” replied the freshly-minted Stanford CS grad.
Ease of adoption and functionality set to cover most used feature of relational database is key to success of MongoDB.
Agree with your points Ajay but disagree that this is why they have been successful. We are seeing ‘Revenge of the Developers Part 2’ (Part 1 being the previous rise of object oriented databases). Front end/web developers want to build apps but data modelling, index optimization, etc. are a pain. Mongo DB allows developers to create apps more easily with little/no regard to the back end. The problem occurs when those developers turn the apps over for IT and DBA’s to maintain. Hence, Mongo DB’s area of investment going forward.
“little/no regard to the back end” is the beginnings of many a tale of woe when you try to scale… I had to chuckle at that.
I had the good fortune to meet some of the MongoDB people about a year ago, and I’ve thought ever since that MongoDB really could be the first really serious threat to relational in a lot of use cases where relational is somehow overkill. Looks like the smart money agrees. Would love to see them do well.
Developers have their heads around workable patterns they can implement in a wide range of use cases, where relational is concerned– patterns that even take into account the needs of operations. And rich libraries have sprung up to steer developers down the right path. I wonder how long it will take to get comparable dissemination of “right thinking” among developers building on MongoDB, and a “right platform” for their use.
MongoDB have to spread the new gospel and get a lot of people schooled on good habits, or else they could get blowback from frustrated adopters of MongoDB who took their old skills with them and built inappropriate solutions that behave badly. (In this vein, here’s a good read: http://ayende.com/blog/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases) Optimizing performance on code where people do what naively seems right would help too… but really, developer education will be key.
I know Cloudera is working on making the Hadoop platform more accessible to the non-expert developer (see the work on the Cloudera Developer Kit– CDK). Perhaps MongoDB will make similar efforts.
Dave,
Quite an interesting analysis. It’s revealing that Gartner just released this week their MQ for Operational DBMS, in which MongoDB is not in a bad position for such a company. In fact, this MQ is made of 2 well separated clusters, which is a clear sign of a market reinventing itself (hypothesis confirmed by tweet exchanges with Merv Adrian). Gartner, with all their risk adversity, is picking a number of “bets” here. Probably one of the most forward-looking (or least backward-looking…) MQs I have seen.
Where I disagree with your analysis is that I don’t think you can put MongoDB and Hadoop in the same category. It would be akin to comparing Oracle and J2EE, or SFDC and AWS (OK, I admit I had trouble finding the perfect analogy, but I think you get the point).
I believe there is room for another NoSQL “co-leader”. The 451 analysis favors Cassandra, and indeed Datastax has good momentum too. Incidentally, MongoDB and Cassandra are the two NoSQL platforms on which Talend is investing the most for enhanced support/connectivity, based on customer & community demands.
Yves,
I agree on the asymmetry of Hadoop and MongoDB, but I still believe that while different (e.g., Hadoop is a whole stack including things that are more DBMS-layer — i.e., HBase) that they will both be winners. My favorite description of Hadoop by the way is as the “world’s sexiest ETL” because that’s precisely what a lot of people use it for. I personally go back and forth on Cassandra; I think it has a shot. But if I stay true to my own analysis, increasing returns should mean that they get relegated in the market. Some folks have asked me for examples of developing categories where vendor X got an early lead only later to be replaced by vendor Y — in a sense a counter-point to increasing returns. In the markets I know best, I can’t find one. Thanks for commenting!
Dave, I really liked you post. Yes, you are right. Or not. I think it is still unclear. My personal feeling is: MongoDB as a company is not there to make technology better, it’s there to make a quick buck. That’s how it looks to me as a naive stand-by person (otherwise they would have a better query language then this, and no global locks, …but that’s another story).
Well, if I am right with this, and given the huge amount of money they got, it seems clear to me that they will not be able to sustain this growth for much longer (money they received seems disproportionate with how fast their technology improves). Art some point they will try to sell it.
What if HP buys it for example? Do you think the Mongo skills will keep up ? It’s just a possible scenario….
Pingback: This Month in IT Technical Standards: October