Hacker News new | comments | show | ask | jobs | submit login
MongoDB Raises $150 Million at $1.2 Billion Valuation (bloomberg.com)
259 points by sethbannon 1510 days ago | hide | past | web | 223 comments | favorite



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!?

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.


> 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.


> Oracle is a frigging database

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.


Oracle had a net income of over $10B in 2013. That's some serious cashflow.

https://www.google.com/finance?q=NASDAQ:ORCL&fstype=ii&ei=lM...


This book is highly recommended by Aaron Levie from Box too. Fantastic book.


Seriously?

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.


> Salesforce is a frigging CRM tool

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.


No SAP is an ERP company. HANA sales have been woeful from what I've heard.

Likewise for Salesforce. They are still very much a one product company.


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.)


Ok, but Salesforce was also the fastest company to ever reach a billion dollars. They are definitely an outlier.


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

MongoDB revenue last year: $36M [1]

[1] http://wikibon.org/wiki/v/Big_Data_Vendor_Revenue_and_Market...


> 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.


10gen's investors might have been cautious then but RethinkDB's investors can't be now. Now they see what the upper limit for RethinkDB can be too.


This evaluation is absurd. And comparing mongo with oracle is even more absurd.


I don't know. I haven't seen these financials.

this made me chuckle. nothing like have a strong opinion based on nada.


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.

I would have named it something like MongoCache.


Actually, it's a really poor in-memory cache, since it pages back and forth to disk constantly.


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.


Our data is 1/10th of available memory and MongoDB still pages back and forth to disk constantly.

This is what happens when you rely on the OS to handle paging.


> 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.


MongoDB is also incredibly ease to install, use, manage and understand.

But hey none of those are important to developers. We are just stupid sheep controlled by marketing.


Because when you chuck it over the fence to ops, it's not your problem any more, right?


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".


MongoDB is a great database if you have a domain model that is more document driven.

And who on earth uses MongoDB for caching ? I've never heard of a single company doing that.


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.


I would stick to in memory cache solutions like redis, memcache over mongo


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.

Memcached doesn't have persistence.


you can write a "cache that persists to disk" in a few lines of C code. ever hear of memory mapped files ?


That with a little bit of Fortran can get you in a big world of hurt.


I'm confused. You do realize that MongoDB uses memory mapped files for managing and interacting with all data...


Yes, I realize this. My point is that it's not a "technical niche", it's something nearly anyone can do, and has been able to do, for decades.


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.


The value of MongoDB is how much Larry Ellison is willing to pay for them. That is that.


Cannot be emphasised enough. Less than 1% of Oracle's market cap; and pretty sure they could complete their offering with a NoSQL database.


Oracle already has a NoSQL database, and from what I hear, it's pretty good: http://www.oracle.com/technetwork/products/nosqldb/overview/...


Yeah. They came in once and tried to sell us on it. Wasn't all that interesting honestly and I believe we'll keep on using Couchbase.


Exactly: Oracle will first try to write the code and if that does not work Oracle will write a check.


Dear "That Guy", spot on.


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.


Enterprise software deals are never closed on technical merit.


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.


Fortunately there is no startup bubble.


Thank goodness for that! If there was, this development would be quite concerning.


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? 8.54BB market cap.


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.


If Linux would be closed source, RedHat would have much more expenses. No more free beta testing from Fedora users.

Also Microsoft and Apple are probably on different market. For most deployments Windows or MacOSx based servers are not even considered.


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.


For every developer you hear that has problems with Mongo, there are probably 5 that are fine with certain downsides.


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.


Would it be possible for you to write a wrapper and use the Mongo API against another DB?


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.


Heh, do you work at my place?

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't you just jam the data into Postgres JSON columns? :)



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.


I've always just abstracted the DB away with objects and lazy-load any 'subqueries' that I might want to have/use/get (or autoload them if necessary).


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.

[1] http://tebros.com/2011/07/using-mongodb-mapreduce-to-join-2-...


So JOIN in your application. Or use a different DB. MongoDB isn't correct for every use case and they would never claim it is.


Am I just too old for HN now?

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.


I don't know, what is the definition of a database? I'd be surprised if it mandated joins.


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.


Hearsay and strawman arguments don't make for an intellectual discussion.


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?


Using partitioning like VoltDB allows you to keep joins. I think Google's Spanner/F1 partitioning/relation scheme also allows joins.


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.


How does CouchDB compare? What are the latest thoughts on this?


If you're having issues with scaling and performance, you're most likely using MongoDB the wrong way or for the wrong reasons.


Begging the question. If this is true anyone having trouble with mongo for legit reasons can be labelled as "using it for the wrong reasons."


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.


Aka "no true Scotsman" fallacy


what are the data type problems?


Support for arbitrary-precision decimal. Known as numeric/decimal in Postgres. This can be a problem for financial and scientific applications.


Yep we canned it because of that, plus it was unreliable and our code and architectural review scared the shit out of us.


Well, some of us have been asking for a native high-resolution time type for three years: https://jira.mongodb.org/browse/SERVER-1460


Can't you just store it in a regular 64-bit integer and know it's a datetime from your application's logic?

What do you gain with a native, high-resolution datatime type?


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.


nobody ever got fired for choosing:

1. Oracle

2. SQL Server

3. MongoDB


Oh but I wish they had


$1.2bn seems utterly mad to me, but kudos to them for getting it.


MySQL was bought in cash by Sun for $1 billion. Of course, Sun collapsed after that, so perhaps you are right about the madness.


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.


You can't buy user base.


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...


They weren't buying tech, they were buying customers.


It wasn't for 1B cash, it was 800M cash, 200M Sun stock.


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.


Instagram was bought for $1 billion, not 2 and had a $500 million valuation at the time.


Instagram had 30 million users. Thats $34 a user. Facebook IPO was close to 100 billion, they had 1 billion users which is $100 a user.


That's not real money, much of that was overvalued Facebook stock.


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.


But the Oracle database engine is arguably a pretty small part of that value.


yes, but the DBMS was the keystone to that value.


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.


Ok. Time to change how the hype and good marketing drive mediocre products, with average people behind it, to silly valuations.

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
Congratulations to MongoDB sales and marketing team (really!). It is a tough job to sell a trojan horse to masses.


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.


Cool, time to make MongoDb web scale! :-)

http://www.youtube.com/watch?v=b2F-DItXtZs


I like this bug report about pymongo (not the MongoDB core itself):

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


One of the best bug reports I have ever read!


Only if you're a 5 year old. It's immature, unhelpful and generally pretty pathetic.


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 */
Seriously?


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.


That video is three years old, though.


...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 know. I added the smiley face because I meant it tongue in cheek.


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.

[1] http://docs.mongodb.org/manual/tutorial/perform-two-phase-co...


You're not alone in this interest - we hear that as a pain point a lot. If you're really interested in this, keep an eye on this page:

https://foundationdb.com/layers

:)


This is more great news for the NYC startup ecosystem.


I wholeheartedly agree. Kudos to MongoDB, Inc. It's a great NoSQL database that's gaining traction.


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.


I think the question is how much effort will it take to get all kinds of data from all kinds of sources into a nice, coherent schema.

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.)


You always have a schema. The only question is if you know what it is, or not.

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.


PostgreSQL has terrible sharding and clustering support.

So no I would not be using it for any big data projects.


I was going by mcphilip's description which was <300GB. For running data mining on so small datasets you do not need any sharding.


Such general statements can only be inaccurate.

We're having about 3TB of PostgreSQL data on 4 servers. It works very well for us.


> "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."

That's the description of a data warehouse.


It's just a buzzword now. "Let's use cloud to do big data analysis to proactively synergise our core competencies".


you forgot "disrupt"


One rule of thumb I've had for people is, "if you can fit it in one computer, it is definitely not big data".


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 guess so and 16 MB was certainely considered too large and complex to process it with traditionel data processing applications a few decades ago.


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...

aka MariaDB :)


I don't quite follow, in that all dual-licensed business models seem to be based on this exploitation? What's different about AGPL?


I bet In-Q-Tel is very happy with this. Between MongoDB and Palantir their recent investments have been doing really well.


They have the easiest job in the world. They invest in a company, then have their deep-pocketed client buy services from that company.


add Digital Reasoning to that list very soon.


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.


Congrats to MongoDB. But for me they became pretty much irrelevant after PostgreSQL 9.1 added a JSON datatype.


Postgres 9.2 gives you the ability to index and query JSON, but you still can't atomically update portions of the JSON which is very limiting.


It seems 9.2 can solve a lot of use cases but when they have partial updates, I'll cry tears of joy.


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.


Yesterday I was just talking to some folks about how they lock on the DATABASE for a transaction. Yey.


Your folks were wrong. They lock on the collection and only on some types of queries.


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."

source: http://docs.mongodb.org/manual/faq/concurrency/


Yes that's the part that just kills me. It was a system-wide lock, and now it's just per-DB. I just don't see how anyone can take that seriously.

Also, why bother with a buffer pool manager when you've got mmap, right?


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.


You're right.

It's still hard to recommend GIMP to someone looking for an alternative to Photoshop.

Mongo is likely to be a similar distraction:

http://www.urbandictionary.com/define.php?term=mong


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'.


With the best will in the world, even with non-technical clients it's hard to not let slip some technical language.


It means the same thing in several other countries, including Sweden.


Do you have issues with FlipCam?


Good, now they only need to deliver a database :)


or, given the quality of existing async/fsync guarantees, they'd be better off with just taking the money and running.. away.. fast


> MongoDB ... now has about 600 customers, including Goldman Sachs Group Inc. and MetLife Inc.

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?


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.


GS probably resells it to unsuspecting investors as a "AAA" database engine. :)


GS doesn't use it for applications that require massive scaling, they already have their own infrastructure in place for that.


That's what I was hinting at. MongoDB, the company, is trading on the Goldman name, but Goldman isn't using it for scaling at all.


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.


Please use this money to buy the TokuTek fork. I always expected the storage layer to have made much greater progress by now.


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.


Curious - what systems has MongoDB replaced in enterprise companies (like Goldman Sachs, etc)?


I think a common answer would be "text files." And of course, grep and awk.


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'd never replace awk.


Mainly in-house made no-sql databases.


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 was already moving away from mongo


I'm curious what you're moving to.


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.


Congratulations to the team ! Finally hardwork they have done is paying off. Hope you will continue to make awesome fast databases like ever !


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.


These valuations makes joining MongoDB right now a very bad idea.


Exciting to think what this might mean for RethinkDB some day. :)


Congratulations Mongo. Hopefully they can keep up the pace of improvements they have done over the past few years.


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.)


Impressive. And they're actually a real big data company, not one just tagging big data onto what they do.


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)


Mongo shards are not the answer: http://aphyr.com/posts/284-call-me-maybe-mongodb

Per the article, Mongo picks just P out of CAP ...


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.


Any recommendations for a good MongoDB book or course?


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

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.


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.


Yep, mongodb is launching their own moocs https://education.mongodb.com


Anyone have estimates what their revenue or run-rate is?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: