MongoDB Raises $150 Million at $1.2 Billion Valuation
bloomberg.com
bloomberg.com
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.
Given their financials and growth figures, how would you value MongoDB?
Look, I'm not claiming to be omniscient. I'm sure they're smart people. But would you buy stock in MongoDB at a 1.2b valuation? Would you?
As for me - Absolutely not.
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.
(Tangent: for anyone interested in Oracle's history/business, or just enterprise software in general, I highly recommend http://www.amazon.com/dp/0743225058)
https://www.google.com/finance?q=NASDAQ:ORCL&fstype=ii&ei=lM...
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?
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.
Likewise for Salesforce. They are still very much a one product company.
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?
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.)
Salesforce revenue in the year of their IPO: $96M. IPO: $110M
MongoDB revenue last year: $36M [1]
[1] http://wikibon.org/wiki/v/Big_Data_Vendor_Revenue_and_Market...
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.
this made me chuckle. nothing like have a strong opinion based on nada.
I absolutely would buy the stock if I had insight into the relevant information and liked what I saw.
I would have named it something like MongoCache.
This is what happens when you rely on the OS to handle paging.
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.
But hey none of those are important to developers. We are just stupid sheep controlled by marketing.
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.
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.
And who on earth uses MongoDB for caching ? I've never heard of a single company doing that.
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.
Memcached doesn't have persistence.
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.
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.
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.
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.
So if you are unhappy paying the money then invest in dedicated people.
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 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.
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.
Also Microsoft and Apple are probably on different market. For most deployments Windows or MacOSx based servers are not even considered.
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.
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.
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.
[1] http://tebros.com/2011/07/using-mongodb-mapreduce-to-join-2-...
I can understand calling something that holds your data and makes it so you don't have to do JOINs a database.
I can understand calling something that holds your data and does JOINs for you a database.
I'm having trouble calling something that holds my data and makes it so I have to "JOIN in my application" anything but a file system.
What do you gain with a native, high-resolution datatime type?
1. Oracle
2. SQL Server
3. MongoDB
It still didn't work, but I don't think they were just trying to buy a database.
Edit: corrected Instagram sale price from 2 to 1 billion, thanks Elliott
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.
So here it comes. It is only a VALUE if WE say it is. So here is what I say.
I value
* Redis @ $4.5B
* Datomic @ $4.5B
* Riak @ $3.2B
* Hazelcast @ $3.0B
* HBase @ $2.5B
* Spanner @ $2.1B
* Neo4j @ $2.0B
* MongoDB @ N/A
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.
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.
https://jira.mongodb.org/browse/PYTHON-532
-
Step 1. Use Mongo as WEB SCALE DOCUMENT STORE OF CHOICE LOL
...
Step 7. DISCOVER PYMONGO DOES NOT CHECK RETURN VALUES IN MULTIPLE PLACES. DISCOVER ORIGINAL AUTHOR SHOULD NOT BE ALLOWED NEAR COMPUTER
if (strcmp(buffer + position + 5, "$ref") == 0) { / DBRef */
That being said, I do wish they can use this investment to do more feature development than marketing.
[1] http://docs.mongodb.org/manual/tutorial/perform-two-phase-co...
https://foundationdb.com/layers
:)
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?
The "schema-less" aspects of NoSQL data stores is a big part of the marketing appeal, I think.
(Maybe the JSON support in PostgreSQL makes this moot, but that's the thinking.)
In the next few years there will be a lot of money to be made getting data out of these stores and back into relational databases.
So no I would not be using it for any big data projects.
We're having about 3TB of PostgreSQL data on 4 servers. It works very well for us.
That's the description of a data warehouse.
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.
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?
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.
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...
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?
aka MariaDB :)
"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."
Also, why bother with a buffer pool manager when you've got mmap, right?
It's still hard to recommend GIMP to someone looking for an alternative to Photoshop.
Mongo is likely to be a similar distraction:
I wonder what services they sell to scale it to those customers. It sure doesn't come that way out of the box. Any Mongo customers here?
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.
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 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.
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.
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.)
Per the article, Mongo picks just P out of CAP ...
For basics, the Little MongoDB Book (http://openmymind.net/2011/3/28/The-Little-MongoDB-Book/) is a bit dated at this stage, but a good starting point.
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.