Hacker News Reader

Comment by venus | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com