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

There is so much work to running a successful business, especially at that scale. Marketing, Sales, Implementation, Support, on top of G&A, and that's not even touching on HR and retaining employees in a competitive market.

There is a reason some people are known as the "business" guys, I think expertise in that area is underrated, especially among people who've only worked at smaller companies or startups.

Edit: Genuinely curious to know why I'm being downvoted. Care to elaborate on why you're downvoting?

That said, I do think they made a way of handling a data model pleasurable. Different paradigm++

What Mongo did is implementing these features just well enough so they can put checkpoint in their marketing brochures.

When you actually start using it you learn that most of it is either performing slow, does not work correctly or once in a while corrupts your data.

Yes they hit these points hard, but only from marketing point of view. They are now universally hated by ops and developers because these people now have to deal with fallout.

RethinkDB actually is an example that database is something that's not good as a base for a startup[1], and the Open Source approach (like PostgrSQL) is more suitable.

MongoDB is example that you can base a startup on a database technology and succeed, if you can sleep well at night that your product can cause people to lose data.

[1] The reason RethinkDB failed was because they refused to provide half solutions like MongoDB, everyone expects startup to start making money, but building a reliable databases is not something that's easy and can't be done quickly.

Let me clarify a bit, I'm not saying that this tactic is invalid or inefficient within our current system, in fact this is a great way to land a good payday if you can pull it off. My point was more that MongoDB is going to implode when their performance shortfalls become visible to the wider populace, if that happens, of course. It's still possible they take the earnings from this IPO and dump heavy into R&D investment to make up the lost ground, but it's also very possible they take this payday and ride out the tech until it breaks down.

They get zero points for this.

It pretty much reads as "Retard"DB in Portuguese, Spanish, and IIRC German.

http://scale-out-blog.blogspot.com/2011/05/introducing-mysql...

Don't put down 'easy'. It's incredibly hard to do well.

P.s., I'm DBMS guy and have lived and breathed Jim Grey-style transactional consistency for decades. I'm still impressed by what they did.

I’ve no idea to what extent this was true, or if it was whether it was their main marketing approach, but it might have been quite an effective strategy: talks at meetups are often 'trusted' to a greater extent than other ways of reaching devs & if you can find a new generation of devs who are just starting out and hook them on your product before they get the chance to explore other approaches then it could work. High cost of course (someone has to pay for all that time) but if it gets you a leg up on your competitors in a $billion business then that’s what the VC money is for...

Downvoted for this. I haven't used docker much but I just did

> yum install docker-ce

and started the service. took me less than 2 mins.

Mongo don't have to be committing fraud, of course. They could be doing any number of actual business activities that make legitimate trades --- but trades optimised at revenue growth, not profitability.

The major metric for companies used to be profit growth. When companies were optimising for that, it was smart to look at revenue growth as a leading indicator. But Goodhart's law ruins everything: now companies know to optimise for revenue growth, and so its value as a metric is much diminished.

Note the downside is unlimited when you short via spread betting. Eg, there's no maximum value of a stock, so you might get proper f'd.

I since turned to RethinkDB and sometimes just a classic SQL will do, but Mongo is really easy to get started with.

That was because it was heavily marketed, not because of timing.

> Mongo was the easiest to experiment with and to get working.

It really wasn't, it was the one they had heard about.

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?

Sony is a worldwide company with 127,000 employees, they alone probably use just about every database system around. So saying sony uses mongo isn't impressive, for all we know it was just a side project from an intern that has 100 documents, there is no context.

And how is that a paradigm shift? Non-relational, non-SQL databases have been around for a long, long time.

Your parent commenter doesn't like Mongo. So it's not production ready.

We used replication on the native apps for offline mode, kept things simpler with online-only for our web app, and have had a very good time overall.

We are also using JSON schema for our CouchDB documents so we ensure we don't have all kinds of wild / wrong data showing up; if you had really hairy, unstructured data, I can see why a dynamic language might help with that bad situation, but for our use case, we were able to take advantage of the powerful replication built into CouchDB and get solid offline syncing for all of our native apps that also plays nicely with live updates in a web browser.

Tell me again how Postgres can seamlessly do horizontal scaling and synchronous replication?

Data stores like Cassandra and MongoDB don't lose revisions. That's not the kind of consistency we're talking about. CAP consistency is just getting the most recent version. You won't lose data -- data loss is a bug, not expected behavior, just like any other data store -- you just won't always get the most recent version of it. And, keep in mind, when we talk about eventual consistency here we generally mean "consistent on all nodes within a few minutes, but we're not blocking reads to write this data." It's not going to take hours.

That said, if you find you get an old version of your own comment, I'd be more willing to believe it's the fact that your request failed with a 503 error or otherwise timed out as much as it was a data store problem. Next time it happens, wait 5 minutes and try again.

> is there really no other way to cluster their data except "one big table"? Maybe like shard subreddits to specific servers ala Hyperdex?

The whole point of MongoDB or Cassandra is that you can get shards without all the headache that RDBMSs usually put you through. You configure your sharding function and let the system do the rest. You don't have to connect to the right shard or anything of the sort, which some RDBMSs do (or did, it's been awhile since I've looked) require with sharding.

Reddit has their code and architecture posted, though it's out-of-date now, it makes it clear that it's basically just two big tables:

https://github.com/reddit/reddit/wiki/Architecture-Overview

It's PostgreSQL, ThingDB, Cassandra, memcached, and RabbitMQ.

https://docs.microsoft.com/en-us/sql/t-sql/language-elements...

> If the transaction committed was a Transact-SQL distributed transaction, COMMIT TRANSACTION triggers MS DTC to use a two-phase commit protocol to commit all of the servers involved in the transaction. If a local transaction spans two or more databases on the same instance of the Database Engine, the instance uses an internal two-phase commit to commit all of the databases involved in the transaction.

I'm only versed in SQL-Server but I'm pretty sure other RDBMS vendors provide similar functionality.

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

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

At the single server level (which is how I think others here are interpreting your comment)? No, they all do, with the exception of some configurations of MySQL (especially older editions, which is why it's often maligned by DBAs). That's what transaction logs do. They're literally a write ahead log (WAL). You commit a transaction, and the DB first obtains an exclusive lock on the affected rows (or page, or table). Any other transaction attempting to read or update those rows will be blocked (with exceptions). It then writes the change to the transaction log and flushes the change to disk. Then it writes the changes to the database file and flushes the change to disk. Then it returns the results of the query to the user. Many RDBMSs let you control how tightly the locks are and the degree that the data are isolated during a transaction.

At the distributed network server level? Then I guess I kind of agree with you, sure. RDBMSs let you "get around" the problems of distributed scaling by not letting you do it easily. SQL servers often only have master/slave or publisher/subscriber setups or otherwise partition the data between instances with sharding. There's no need for raft or paxos type algorithms because they don't attempt to implement a true multi-master environment. There's either a fixed overall master, or each server is the deterministic master of it's own little world, so you avoid consistency problems with distributed data. However, in doing so you sacrifice availability, since if a shard goes down so does all that data, or if the master is busy then you can't always submit queries to the slaves. Replication is used for redundancy, not scaling or load balancing. The solution RDBMSs had was sharding + master/slave replication for redundancy, which can get messy fast and has issues like hot spots or limited queries or variant performance. It's just a lot harder to do than it feels like it should be, and with storage as cheap as it is it feels like a waste of effort.

That said, some RDBMSs do allow you to use multimaster, bidirectional, or peer-to-peer replication, but most of those configurations basically warn you that you're sacrificing consistency by doing it and all of them that I've seen are a huge pain in the ass that makes shard + replicate look like child's play. They also have schema requirements that make life difficult, and they're somewhat notorious for being difficult both to administer and develop for. You have to design the whole thing from the ground up to work with this type of replication, it still feels like a house of cards, and it's this exact level of pain in the ass that encouraged the partitioning and availability focused NoSQL data stores.

However... most applications don't need that kind of scaling. They don't need a database in every time zone for single millisecond response times globally. They don't have the users to demand it, or don't have the quantity of data to require it, or have other requirements that make a traditional RDBMS desirable where you can't accept a system that allows for out-of-date data (which is when PACELC theorem kicks in because NoSQL typically doesn't have locking like an RDBMS does to mitigate this particular problem).

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

Cassandra as well doesn't require a full quorum to acknowledge writes. It just relies on the closest node. Likewise for Oracle.

http://docs.datastax.com/en/archived/cassandra/2.0/cassandra...

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.

This talk is a pretty nifty perf overview:

https://www.percona.com/live/e17/sessions/high-performance-j...

That said, if you know beforehand that horizontal scaling will be a crucial factor, probably postgres isn't the first choice. But with how fast CPUs are these days it's usually not important for a long time.

Think of it as an additional cost of underwriting just broken out in a weird way and it might be more palatable.

If you want a lot of interest in your IPO then you probably need underwriters with big institutional relationships. The underwriters with the best relationships are going to be the ones who help their clients get good returns. You're just paying for better underwriters by losing part of the pop instead of paying them fees directly.

Companies are free to go to smaller underwriters in exchange for an IPO price that's closer to what the underwriter thinks the market will bear. And yet most of them choose not to.

Given that almost every IPO has a pop, what do you think is most likely

* CEOs & VCs taking their companies public don't realize that they are leaving money on the table by underpricing the IPO. You have two groups of sophisticated finance people and the underwriting side always manages to fleece the company going public.

* There are structural reasons and incentives for creating an IPO pop

You can't even accuse people of trying to fleece the low-level employees and retail investors. The employees are locked up either way and whether you have a pop or not, by the time the shares reach the retail investors they're the same price either way.

I do another one and someone told me there's a technical name for it. I forget the name.

When I go shopping, I'll discretely look in shopping carts. I'll make a mental note and check to see how well the shelves are stocked in comparison to other products. If I see a lot of the same company in carts, to the point where the store hasn't matched stocking well, then I'll look further into the parent company.

So far, it has done well. I'd never played in the market before and my 401k was always managed. So, this is pretty new for me. I've been at it since maybe 2011.

I did the same thing with Tesla, though they were $24 at the time.

I've written about this before, here in HN comments. I often make stock choices based on the commentary at sites like Slashdot and HN. No, I don't listen to people saying to sell or buy, I listen to the hype and commentary about the companies themselves. As another example I did well with Yahoo!

To be clear, this isn't serious money. I have someone who professionally manages my finances. This is more an experiment and is meant to to play around.

I know, that probably sounds a bit terrible. But, it's not money I am worried about losing and I'm actually doing pretty good at speculating. I make greater returns than the person who does it for me - which is to be expected. I take a bunch of risks, don't do traditional research, and don't even check the daily prices.

I have no idea what his sources were for this, but it signals Mongo's marketing power to me if a non developer would become so avid about it.

And the reason for them being non-defaults is that it will drastically reduce performance.

Edit: Also looks like Kyle saved for the next time testing of server crashes and restarts which is another difficult problem to handle when performance is important.

But I do think http://www.scylladb.com/ is great.

Interestingly enough, many of those techniques are common in the NoSQL world as well — a billion records is enough to require thinking about data flow anywhere — but the difference is that you have to deploy them more frequently.