The point is that the query I mentioned requires joins. You can of course get the same information from key value pairs, it will just require a number of scans over all your data, which doesn't scale if you need the queries to be fast. On the RDBMS side, there has been more than three decades of research on optimizing patterns like this. You don't want to try and reinvent that.

If you can know for sure from the start that you'll never need queries like this, then of course something like Mongo will be awesome. But requirements change, hence this article.

You saw the part where I said that all the forms had different schemas and were in different collections? The RDMS equivalent would be all of the different types of forms would be in different tables and each user would have their own database. You would still have the same issue where you would have to query the database’s metadata to get all of the tables and programmatically join the data.

At another company where I worked where we used Postgres, we had a multitenant set up where each of our (large) customers had their own database. The issue would have been the same.

You would no more “scan over all of your data” with Mongo with indexed fields than you would with an RDMS with indexes.

MongoDB has supported some types of joins for years now, you can do quite a bit with MongoDB aggregation pipelines. https://docs.mongodb.com/manual/reference/operator/aggregati...

As requirements change, you do need to migrate your data into a schema that makes sense and that's regardless of whether you're using SQL or MongoDB.

Yes Mongo supports joins. But, I wouldn’t use them. Application servers scale much easier than database servers. You’re not getting any efficiency gains from doing server side joins over just reading documents from the left side and doing an “in” query with the ids from the right side. Assuming you are doing the equivalent of a left outer join.

In fact, if you are using C#. You could use the same LINQ syntax either way.

The OP just said it would be hard to do that query (regardless of performance) and I'm saying it's totally capable.