Live data from Hacker News

MongoDB shares jump more than 30% in $192M IPO

cnbc.com

91–100 of 425 posts

Re: MongoDB shares jump more than 30% in $192M IPO

#91

Earlier quoted context omitted.

> it's an unlikely success story that deserves admiration Well, it's a success story due to marketing, smart marketing, clever marketing, and more marketing, not due to lots of technical merits. And it was not the first document store to appear, just the most successful. For starters, CouchDB was previous to MongoDB.

Couch was a nightmare to use, mingo made all the friction to get it into products go away, especialy when teamed with dynamic languages.

Did you really find CouchDB that bad to work with? I never in the end settled on either couch or mongo for a project long term but when I setup couch to test it out a few years ago I had it up and running with functional replication quite quickly (i.e., one afternoon) from being a complete novice with the platform. It's built in web panel at the time basically handled everything from basic setup to replication quickly.

Re: MongoDB shares jump more than 30% in $192M IPO

#92
post #27

Earlier quoted context omitted.

It really is an interesting story. They aren't best in class in any of the metrics we think of as mattering. It's not the highest scale system out there. It's not the most durable. Or the most available. Hell it's not even particularly reliable (at least throughout its history). It is however..simple. Very simple. It's easy to reason about. It's easy to setup. For 90% of use cases it's very easy to administer. It tur…

> It's easy to reason about. ...until it's not. Then it's really not.

But how many people reach this stage ?

Re: MongoDB shares jump more than 30% in $192M IPO

#93
post #64

Earlier quoted context omitted.

RDBMS makes sense for most applications. Most applications store data that can be fit to the relational model. Most applications aren't big data or data mining OLAP. Most RDBMSs can do key-value stores very well now. Most applications also care more about consistency over availability, which is what RDBMSs do (CAP theorem). Many NoSQL data stores choose availability and partitioning and sacrifice consistency (i.e., "…

You don't seem to know this, but no traditional RDBMSs actually provide CAP consistency, for that they would have to use at least two-phase commit or something, but they don't. So, they all are noCAP databases. Electronic health or financial records are way safer in a proper eventually consistent database, like orders of magnitude safer, but everyone just takes the risk with some insurance at best to cover the losses…

In certain environments, it is better to fail then to have data that isn't immediately consistent. Finance and healthcare are two such systems. Availability is not always paramount.

https://en.wikipedia.org/wiki/Database_transaction

https://en.wikipedia.org/wiki/Atomicity_(database_systems)

Re: MongoDB shares jump more than 30% in $192M IPO

#94
post #28

Earlier quoted context omitted.

> That said, it's pretty hard to make sense of when you would want non-relational dbms these days. Write-scaling is still a pretty obvious reason, though things like Citus might help here. Personally, I find a non-relational database useful when my data model is non-relational.

What is an example of non-relational data? A tree is relational. Each child has a relation to its parent. I can't imagine data that has no relation (no connection) to anything else. Maybe what you meant was heterogeneous (e.g. data elements that do not all have the same attributes) - but even then I can't readily come up with an example.

instead of non-relational, think of it as denormalized. I also can't think of any cases where you wouldn't want some relationships. I can absolutely rattle off tons of cases where applications benefit greatly from some kind of denormalization.

In years past, people called these "data warehouses" and essentially took snapshots of their production DBs and denormalized the hell out of them so that aggregations wouldn't crash the server.

Re: MongoDB shares jump more than 30% in $192M IPO

#95

I don't understand why everyone is so happy when IPOs go up and make it sound like a good event. I see it as the founders needlessly missing out on 30% of money (in this case), which ends up going in the pockets of the Wall Street middle men that get first access to the stock offering.

The company "missed out" on the money, not the founders right? The IPO wasn't with the all of the founders shares. They may also be restricted on when and how much they can sell. Part of the value is creating buzz.

If you IPO at 24 and it jumps to 32, hopefully it is still 30 when you can sell. If you IPO at 32 and it drops to 26 cause there is no buzz, you make a lot less when you sell.

Re: MongoDB shares jump more than 30% in $192M IPO

#96
post #26

Earlier quoted context omitted.

They even got through Jepsen just fine after wiredtiger. With non-default settings[0]. The Jepsen tests passed with the "linearizable" read concern. The default read concern is "local", which "Provides no guarantee that the data has been written to a majority of the replica set members (i.e. may be rolled back)."[1] This is like having "READ UNCOMMITTED" be the default read level in a traditional database system. The…

These kind of default settings make sense, though. If you really care about lineair writes, you know how to configure it. Same goes for example for PostgreSQL [1], that uses Read Committed rather than Serializable transaction isolation by default because for the majority of the people, this is fine, and the performance tradeoffs are worth it. [1] https://www.postgresql.org/docs/9.5/static/transaction-iso.h...

Yeah, and you can turn off fsync in postgres if you want a blazing fast db that loses your data. :D

Re: MongoDB shares jump more than 30% in $192M IPO

#97

Earlier quoted context omitted.

Except when you poison mindshare. For example, I used Mongo back in the early days. Was terrible. I will now never use it again. I don't care if it shoots lasers. It is dead to me. Obviously the happy developer count is way more than the hate it for life count, so I am the odd man out here. Perhaps many users never actually had many GB of data or had to deal with the data loss side of things?

[apparently my opinion is unwanted]

lol, the things you read on HN, very entertaining.

Re: MongoDB shares jump more than 30% in $192M IPO

#98
post #65

MongoDB isn't usually seen favorably but everyone must admit that it's an unlikely success story that deserves admiration. Think about it. Bringing a database to the market with a completely different paradigm, growing it to the enterprise-production-ready level, and creating a billion-dollar business around is no small deal. Yes, they did ride the NoSQL zeitgeist but they survived when others had no major success. U…

If they had done so by presenting a product that was picked up due to it's merit and continued to gain traction based on that then I'd be rather impressed. Instead the story of MongoDB seems to be how extremely well targeted marketing and sales can build a so-so product into a huge IPO, there have been performance comparisons showing it isn't even the best at what it does so this IPO is riding on the network effect o…

Most people forget that with startups, what you are trying to create is a business... the technology behind is only one element to it.

It is extremely difficult to do good marketing and sales and they did it.

Solve a customer problem while building a healthy business... a success story in my book.

Re: MongoDB shares jump more than 30% in $192M IPO

#99
post #64

Earlier quoted context omitted.

You don't seem to know this, but no traditional RDBMSs actually provide CAP consistency, for that they would have to use at least two-phase commit or something, but they don't. So, they all are noCAP databases. Electronic health or financial records are way safer in a proper eventually consistent database, like orders of magnitude safer, but everyone just takes the risk with some insurance at best to cover the losses…

In certain environments, it is better to fail then to have data that isn't immediately consistent. Finance and healthcare are two such systems. Availability is not always paramount. https://en.wikipedia.org/wiki/Database_transaction https://en.wikipedia.org/wiki/Atomicity_(database_systems)

They only guarantee consistency as long as you don't use them over a network, i.e. communications with the database are always reliable. But once you do use them over a network - CAP theorem comes in and forces you to either use something like two-phase commit or no promises of consistency. Which is the opposite of what his post implied, like there is CAP consistency with those databases. But there never was!

Although I kind of got used to RDBMS crowd not understanding consistency, it's just another technology cult.

Post reply on HN