[mattparlane]

I'm still in charge of a production system serving around 2,000 small to medium websites from a 2-machine MongoDB cluster. It's been running on MongoDB since around 2010 and we have NEVER had any issues.

I accept that the unacknowledged writes was a bad decision, but IMHO if you deploy a new database without reading the documentation, you have bigger issues.

The reality is that there are some places where speed of movement is important and referential integrity is just not that big a deal. We're not all building banking systems.

[jacques_chester]

1. Writing DDL is not hard. It's just not very hard.

2. You can go from strict guarantees to looseness safely, when you demonstrably need to. The reverse isn't true -- it's easy to wind up realising, much too late, that you actually needed particular guarantees that you didn't even think of.

Relational databases didn't become incredibly popular by accident. It's because they were a drastic improvement -- theoretically and empirically -- on the generation of NoSQL databases that preceded them.

[wolco]

Why do we always go from one extreme to the other. Mongo is great at handling large volumes of schema-less data. Relational database are great at connecting two datasets.

If you are just using one table with two fields (id/value and value contains a json object that changed) for logging perhaps a relational database isn't the right choice. Redis might be better / mongo might be better depending on what comes next.

Let's stop the next cycle where everyone moves to postgres for everything only to throw it away for the next thing. I was using postgres in 2008 and it was great.. why did it take until 2019 for everyone else to discover? We are in the peak postgres cycle. I hope it doesn't get disgarded when the serverless hype kicks into gear.

[scarface74]

Writing DDLs are hard when you don’t know in advanced what the schema is or the schema is changing frequently.

A lot of things “become popular” but that doesn’t necessarily mean they are good.

[aeorgnoieang]

All the SQL databases with which I'm familiar support large string columns. What's the downside to just stuffing your schema-less or volatile-schema data in one of those?

[scarface74]

The downside is that you can’t easily query against the individual fields and you can’t index individual JSON fields.

I’m bringing up C# again...

Querying with Mongo using the Mongo driver in C#....

  var people = db.GetCollection<People>().AsQueryable();

  var seniorMales = from p in people where p.Age >= 65 && p.Sex == “M” select p;

Querying an RDMS with EF:

  var people = context.People;

  var seniorMales = from p in people where p.Age >= 65 && p.Sex == “M” select p;

Both queries get translated to their respective query languages and run on the server. C# enforces the types in either case and you get compile time type checking and IDE Intellisense. In either case you can index the Age and Sex fields.

NoSQL databases aren’t “schemaless”. Mongo understands the schema of JSON data and can query against it just like an RDMS understands rows and columns.

[Fins]

I have to say that when I worked with MUMPS (and even then MUMPS was older than anyone who thought up Mongo) we've never lost any data.

Too bad GlobalsDB went nowhere...

[mverwijs]

Which is exactly what the author writes. "Was it ever the right sollution? It depends."

[Moter8]

Seems logically invalid.

If you gave to answer "it depends" on a "was ist ever", you should have written "yes" instead, imo.

[dsjoerg]

Actually the author writes: "So was MongoDB ever the right choice? Yes, of course it was; like most things in engineering, it depends."