Sorry for the late reply… as @kbrooks said, I was referring to database transactions. I’ve been working for way too long with enterprises where losing a piece of data isn’t acceptable and unfortunately MongoDB doesn’t fit that kind of customer.
This problem is very similar to using microservices that handle very specific tasks and that work on the same or even different databases independently. There are many ways of solving this issue but none is trivial though.
I was in the same boat until about a month ago. Mongo is great for about 90% of the things you can expect to do with a web application. But it starts to fail miserably when you want to do more complicated relational queries because its not a relational database. At the end of the day, you need to use the right tool for the right job. This is why I built ccorcos:neo4j and ccorcos:any-db. Take this example:
Users can star posts and follow other users. When a user logs in, I want to give them a feed of posts that have been starred by the users that user follows.
Is isn’t something that Mongo can do with any degree of efficiency. And I’m not hating on MongoDB either. Its about using the right tool for the right job.
Great points, Chet.
I’d say that MongoDB gets you a great base database, but as soon as you start doing specialized things with your apps, you need to “use the right tool for the job.”
For example, if you’re ingesting a lot of data, you definitely don’t want that data coming into your app database (especially when it’s MongoDB, and super-especially if you’ve got Meteor acting as a MongoDB oplog subscriber!)
My point to all this is that MongoDB doesn’t just fail you randomly or unexpectedly, and it has more strengths than weaknesses for web apps — MDG made a great choice IMHO, and I’ll continue to use MongoDB as my base app DB. Not sure we hear enough defense of MongoDB in the wild 
hence this post.
BTW, talked with your brother Sam last week — great dude!
-Ry
haha. he gets around!
Yeah most of the features that MongoDB has been bashed for not supporting such as joins and transactions appears to be making its way into other distributions of MongoDB such as Percona MongoDB server. The future of MongoDB applications look bright.
A GPL license is a concern. Suppose I have a code that uses and links to a GPL library, then my code is polluted as GPL. I may need to open my source. If AGPL of MongoDB excluded the source exposure through a Database Adapter, that will be no problem. The IPs of all Meteor codes will be safe. This is very important to enterprises.
The key point is AGPL vs. GPL.
Another pros to use MongoDB even it is GPL is just to use it as backend services. Your entire Meteor codes is built for services and not to be published.
To SQL vs NoSQL both has its own application fields. SLQ is good for financial transactions while NoSQL is good for logger and users management. The debate of which is good is similar to Orange vs Apple.
NoSQL shines when you have situations where a fixed schema does not really fit.
Think of an online store that doesn’t just sell guitars but strings, reed instruments, brass instruments and amplifiers to boot. Each product category has different characteristics you might want to select over. Amplifiers have power ratings. Strings have sizes.
NoSQL handles this with ease. It’s just a document store that doesn’t really care about the contents of the documents. Each document can have a different set of fields all within the same collection.
SQL would require a separate table for each product type or a single table with 512+ fields most of which would be empty.
The strange thing I’ve noticed is how people have a tendency to enforce a schema on NoSQL databases on the client side. If you want a fixed schema you should be using SQL.
You are absolutely right. NoSQL is better to solve schema version problem. In one of our SQL database, we need to add new fields in later versions, that led to modify entire program and upgrade to new tables. Old data is not readable. NoSQL really help to solve this software engineering problem. But many IT departments do not care of this, they need to keep busy to raise their levels in a corporation
One reason for us to use Meteor is its tight integration with MongoDB.
Sql also handles it with ease:
You can also use json type in Postgre for this task if you want 
People are forced to use Mongo as relational db only because Meteor does not support another db’s…
This is only because of bad database architects.
This is natural. Nobody can define everything right and complete initially. Software is an evolution product. Someday in the future user may need to add an new filed and nobody knows when.
Yes, I agree with you, but I can’t imagine a case, how some new fields can ruin a well-structured relational database.
There is no such thing as a well structured NoSQL database when you consider intentional denormalization is a rule of thumb.
One problem that I’ve never really solved is how tightly coupled an SQL schema is to the application. Adding a field is often easy. Changing an existing field can be a nightmare as you always end up overlooking it’s use in one method/interface or another no matter how diligent you and your IDE are.
I generally do my best, then let the application blow up to find the rest.
I think, Mongo is good in some cases, we just don’t need to use it everywhere. I really don’t like denormalisation and I think it is not, how Mongo is supposed to be used. It also leads to a lot of problems.
Yes, relational data is usually tightly coupled with models so I try to have all db related things in models / repositories - this is how we can limit the area of search if we will need to change something. I understand what you are talking about.
The more you use relational db’s, the better you can create and predict its structure. I actually find database modeling satisfying, but maybe it’s just me.
Old version of database file need to be converted to new version of database. This procedure may have lots of version management problems. There might have many databases distributed many places. By using NoSQL old version of database can be read by new software and save to new version of database. This is a smooth migration.
Some example issues that should be solved.
It just has a lot of “silly” limitations. I always feel like I am using the alpha version of software. Take for example if you want to find out if an array exists and has more than 1 item in it.
Customers.find({
'orders': {
$exists: true,
$size: { $gt: 1 }
}
});
This doesn’t even work. It’s very frustrating.
Honestly, I think that mongo would be great on the CLIENT somehow. That is, just some kind of temporary data store that can sync with the server at some point. But on the server? Nah. Relational databases are much more established and predictable