Comment by benatkin
7 years ago
I skimmed the post and am not interested enough to look at it further. I'm not saying it isn't interesting at all, but I still need to carve out the time to learn Postgres' new features and check out RethinkDB again. If I had infinite time I would check it out.
The MongoDB example is extremely contrived. If you wanted to do that with MongoDB you would add a new field or a new collection with full_name rather than doing a $map.
The comment in the query mentions that it makes the query only 5% slower. You can drop the "full_name" part, but the query would be still too low level (even compared to SQL/ORM examples) and slow.
Why are you combining separate fields in the first place? Document databases are denormalized. If you want a fair comparison, put full_name in a separate field in addition to first_name and last_name in each document. That's the way to use Mongo. The issue here is that a document db takes extra space, not that you have to use $map for the common task of searching a full name. You only have to use $map for querying things that you didn't plan to query.
The point of that blog post is to look at both performance and usability.
MongoDB has a way to fetch data the way we needed and the way other databases fetch it in our benchmarks. We tried just that: the performance is roughly the same anyways. It's up to MongoDB users how exactly they store the data and how exactly they query it, but it's nice to know that their query language is capable enough.
I think that it's pretty obvious that not a lot of users query data like that in MongoDB and instead just store denormalized data. That's not the point of that blog post though.