[tikiman163]

To be completely frank, I'm seeing less and less reason to use traditional sql databases. MongoDB offers the ability to make sql queries and even has Acid transactions. Everything SQL can do, it does without slowing down when dealing with big data. The only thing it doesn't offer an efficient solution for is something SQL can't do either, and that's advanced search engine capabilities like Elasticsearch provides.

Some people will argue that PostGreSQL is better in certain ways, but the argument really always comes down to 2 factors. Are you going to hit the cost efficiency performance limits of traditional SQL servers, and do you require advanced searching capabilities like graph queries or synonym matching. Even if both answers are No, I'd still argue for Mongo because it makes it easier to distribute Acid compliant coppies of the data by region, providing backup redundancy as well as fast responses in multiple regions.

[Youden]

> MongoDB offers the ability to make sql queries and even has Acid transactions. Everything SQL can do, it does without slowing down when dealing with big data. The only thing it doesn't offer an efficient solution for is something SQL can't do either, and that's advanced search engine capabilities like Elasticsearch provides.

You seem to be looking at this solely from a perspective of what kind of queries you can run but there's a lot more to it than that. For example how do you model and maintain relational data, which I'd argue is most data? Does MongoDB have support for foreign keys or something like them these days? A quick Google brings up DBRefs but these seem very soft.

[OOPMan]

You made the point I wanted to make without sarcasm. Thanks :-)

[Youden]

I don't want to sound too preachy but I find it often helps to assume the best of everyone. Most people aren't idiots, they just see things differently sometimes.

I thought about it a bit and I think that if you see something you disagree with or think is silly, usually that person either has different priorities to you (e.g. they might work in a document-centric company) or might just not have the same knowledge or experience. Either way, if you state your assumptions (in this case "relational data is important") and ask a question ("how does MongoDB handle this"), you should usually be able to trigger a respectful and productive discussion.

Of course sometimes there are just arseholes and trolls on the internet, in which case you can usually tell quickly and stop engaging.

[vosper]

I manage a team that's responsible for the Mongo DB that powers essentially the whole business. This is a 10 year old company that started right about when Mongo was trendy. After 10 years it's a nightmare to understand what's going on in that database.

And it's now extremely difficult to get off of it precisely because it doesn't have the schema and referential integrity and constraints that we need to be able to understand our data well enough to actually do the migration. We really want to switch to an RDBMS, but it's going to be risky and difficult.

You could say this is all bad engineering, and I guess that's true in a reductive sense. But it's like arguing that you don't need to climb with a safety rope because good climbers don't fall. Over 10 years and many engineers "bad" engineering happens.

I also believe that reasoning about data is hard, and you should therefore try to avoid doing it. You should do that hard thinking one time, and then rely on your database to enforce the rules until they need changing. Aka: Don't Make Me Think (About This Constantly).

If I believed in conspiracy theories I'd say that Mongo was one of the best vendor lock-in plays in tech. Mongo Corp is going to be profitable for a while because once you're down the Mongo rabbit hole it's a real pain to climb back out. But they'll host your database at least, so you don't also have to deal with that. I will give them credit for having a nice management UI.

But from my experience of the past few years I would never choose Mongo. For documents, Elasticsearch, or Postgres if you don't have too many. For relational data, a relational DB.

And Mongo's slow, too.

[OOPMan]

Riiiiiiightttttttt, because having well defined data is not useful at all.

[winrid]

You can have well defined data and use Mongo. Those two things are not related. I worked at a place that used Postgres and put an object w/ 11k unique paths in a single JSONB column with no schema or documentation whatsoever.

[winrid]

... and this system was responsible for billing, and many other things....

[unnouinceput]

and? That's not PGSQL fault, is the DB architect (or lack of) fault. You definitely can drive the safest car in a ditch, no?

[winrid]

That was my point right? It has nothing to do with the DB.

[throw1234651234]

Also, MongoDB queries for related records can be painful. This takes a while to realize, but definitely shows itself when you are working with more complex data.