MongoDB has filed to go public

How the hell does this company spend $188M a year?!

Seriously I'm flabbergasted.

Mongo going public for same reason all tech companies go public in 2016+ - they are done growing, they are not going to win it all after all, they're fucked, and now the investors want to liquidate

What are the chances of that revenue doubling any time soon?

This is probably not the answer you're looking for, but MongoDB no longer has much technical justification.

Compared to Mysql and Postgres, it does have an out-of-the-box partitioning scheme, which is something, and a reason to use it (although I'm not sure it outweighs the downsides).

Compared to newer cloud databases like Spanner, Citus, or Aurora which scale well but also provide your with ACID guarantees reminiscent of traditional RDMSes ... there's really not much there.

We use it for our database engine, as the nature of our data does not work in a SQL table. I work with DNA sequencing, and we store our data in a sample metadata, feature metadata, and sample-by-feature count table.

So our sample metadata has the generic metadata about each sample (where it's from, when was it collected, etc.). Our feature metadata is the particular feature metadata (DNA amplicon sequence variant, taxonomy, all seven taxa levels pre-split). These would work perfectly fine in a standard SQL database, but the problem is when we get into our sample-by-feature table/collection. Currently, we have over 400k unique features and tens of thousands of samples. If we were to try and map the frequency of each feature in our samples in a standard row/column relational database table, our table would be un-usably large (or just entirely not work as PostgreSQL, MySQL have a hard column limit). Thus, the benefit of MongoDB's document system fixes all the issues this causes.

Each of our documents in the sample by feature table can consist of ONLY the counts of the features that were in the sample, ignoring all the other N-thousand features that may be present in others. Building a pandas DataFrame from a query of this data will just fill the absent features with NaN, and we can just fill those NaN's with zeroes and carry on working with our target subset of the database.

I've been using and relying on MongoDB for years (since 2010). It's pleasant to develop for, the query interface is awesome, and the library / ORM support is top notch (Mongoid on ruby, and Mongoose on node).

I also use Postgres regularly so I can compare the 2. And in my experience, I always enjoy working with Mongo more.

Many people don't care about the developer experience and rather focus on Mongo's lack of features like joins and transactions. There's definitely tradeoffs to choosing Mongo and I wouldn't criticize anyone for picking Postgres over Mongo, however the amount of belly-aching about how Mongo is "the worst" was always pretty ridiculous.

We use MongoDB to build eCommerce apps at my company, using a Ruby-based platform that can be easily extended. Here's a couple of the reasons why we use it:

1. It's easier to extend the pre-defined model classes that our platform provides with new fields, without having to manage migrations. Mongoid manages the schema for you.

2. Because our apps represent an eCommerce "storefront", they are _not_ the system of record for our clients. Each client has their own way of storing this data, and fulfills orders through an order management system. They control all of that, obviously, because it contains important financial data that they need to retain.

3. MongoDB is a well-supported database, with a large ecosystem and lots of users. It's a familiar DB for new developers that we hire, as well as for systems integrators who are also building apps on our platform. Using MongoCloud and official support from MongoDB, Inc., hard questions about our database technology are just a phone call away. Postgres is amazing, but it isn't supported by a company you can turn to when shit really goes south, so it's a scary choice for enterprise service providers.

4. It doesn't have terrible documentation. Pretty much everything is there, it's just hard to find. I really wish they would use something other than Confluence because the search on there is awful.

All this aside, I still use Postgres on my own Rails apps because I don't need the complex features of MongoDB. But after a few years at my current job, I can definitely see why Mongo was chosen.

NoSQL has real use cases. The model is much closer to how you usually are structuring and handling data in your application. If you application is handling hierarchically structured, variously shaped, low-relational data - which many are because that's pretty much the default for how programming languages work - and does it's data processing and validation at the application level, then it can be nice to have a storage system that matches that closely.

It's that situation where a single structured User object would "foil-out" to like 10 de-normalized tables. It feels ridiculous. It often is a bit ridiculous. Also, I'm not sure how much Open Source RDBMS have improved in the last 8 years, but I know for a fact that MySQL used to just melt under joins like that with any serious load.

As far as the recent OS RDBMS JSON additions, they're just that - recent additions. They feel tacked on. They're treated differently then first-level values. Support in ORMs is lacking. It's hard to find examples online. They're not nearly as easy to use and well supported as hierarchical data is in systems build around it from the ground up (of course).

As far as why MongoDB... because it's the most popular solution. If you hit a problem, someone had probably hit it before, and you can probably find some material online. The leading drivers and libraries are relatively mature and widely used. It makes it a much safer bet as far as tractability of issues you will hit.

I don't really like MongoDB, but the case for using it seems pretty strait-forward to me.

>What are the best use cases nowadays for Mongo?

Prototyping apps with little relational data.

Logging.

I've been doing a stack that uses Mongo, Sails and Vue for about a year now. What I like is that it feels like I'm just writing Javascript all the way from front end to query. Mongo queries are just JSON documents. I'm not sure how nicely Postgres queries would work in Nodejs? Can I just feed it a JSON object that represents a query and it will "work"?

The aggregation pipeline is also quite nice. I actually prefer it to Elasticsearch aggregations now. I've done some reasonably complex queries involving grouping deeply nested arrays of embedded documents, etc. using the aggregation pipeline.

Put it this way, with Elasticsearch when you have nested documents and the schema is variable and you want to do aggregation you end up in mapping hell. There is none of that crap in Mongo.

Ease of use - you can get a lot done with only one developer

Mongo doesn't have JOIN pain, sparse tables, many to many join tables, etc - all stuff you need programmers for on sql

This is like saying "The iPhone is not better than Android". There is room for multiple offerings with different strengths and paths to market appealing to different types of users.

It's a bad strawman to say that PostgreSQL is ACID and MongoDB isn't. Here's the thing: even PostgreSQL isn't ACID when you throw replicas into the mix. And PostgreSQL as it stands "doesn't scale" past a single box, not if you want to do (most kinds of) replication or sharding.

The impression I get is that at scale, you don't really "need joins" and multi-table ACID for the kind of workload that MongoDB is targeting, i.e. massive throughput embarrassingly-parallel low-latency OLTP short requests that do point queries and point writes. It seems to be atomic, consistent and durable enough for that [1].

For analytical queries that really do need expressive SQL features, you generally wouldn't want to run them on the same database anyways, not when you're "at scale" and your seven-way join could impact other request latencies. You export it to Redshift or HDFS/S3, and do all the reporting/BI/analytics on it.

[1] https://jepsen.io/analyses/mongodb-3-4-0-rc3

Mongo is quick and dirty. If you're writing NodeJS, chances are you don't care about `what's best`.

Also, what does Mongodb offer that other NoSQL stores like DynamoDb, Bigtable, Azure Cosmos DB etc don't? I'm genuinely curious. I believe there's ACID support on these as well (Probably on by default on Dynamodb).

Made me laugh =)

Had a good laugh at this.

Wasn't that a third-party going public about MongoDB, though? I don't think that counts.

I miss XtraNormal, the videos have a special deadpan quality to them.

Haha, I have watched this video for 10+ times! It's hilarious. Couldn't help it...

This is a great video, and accurately sums up MongoDB and NoSQL. I can't imagine why they need to raise money, why they spend so much money as it is, and why they think there's a big growth business in NoSQL.

> I don't have to deal with database migrations

We've actually just started having the pain of Mongo migrations; adding indexes to large collections. If you just create the index on the primary and let it propagate throughout the cluster, then it will block further oplog replication on the secondaries and the whole cluster will go down for majority writes. The proper way is to take each secondary out of the cluster in turn, add the index, then step-down the primary and migrate it.

It's just as much of a pain as migrating your favourite SQL database, although at least you don't need to do it for small collections and for adding columns (which is a big bonus).

I wonder how it feels to be running or working for a company that develops a product that almost all informed members of the developer community think is bad. They must be in some serious denial.

Let's try to keep the discussion out of the gutter, please.

Reliability-wise, it sucks. Maybe it's gotten better recently, but I still probably wouldn't trust it.

But is there a document store out there that's faster than MongoDB?