Unfortunately this application is new, so we haven't yet seen the benefit of schemaless data changes.
I'm not saying it's a bad decision or that MongoDB is bad in general. I'm saying it's a decision that should not be taken lightly. If you've done the analysis and feel strongly that MongoDB's the perfect fit, then cool.
However, I think people routinely discount the operational overhead that comes with using something like MongoDB. For example, they don't think about how it's much harder to find good devops people with experience maintaining a MongoDB sharded cluster, or they don't think about what happens when the CFO wants to hook the DB up to Excel and run some queries. And I'm not even talking about the additional development complexity due to implementing integrity checks and manual transaction rollback/compensation in your application code.
Those problems can be all be solved though. It just takes more effort/money. So, you need to be sure MongoDB offers advantages to offset that.
In my opinion, schemaless data changes are not even close to offsetting the overhead, and concerns about scaling beyond MySQL or PostgreSQL are probably premature optimization. Not that those are your reasons – just reasons I often hear.
And of course, I'm making a lot of assumptions, for example that the team has experience writing & operating systems on top of an RDBMS. If the rest of the team are MongoDB wizards and you're the only one new to it, then that's a different situation.
The E/R information between tables remains exposed and enforced, but the content details can be made fungible where desired. There is an extension to include JSON fields in queries, as well, though it won't be as fast as using a real column with an index on it.
If I was leaning towards NoSQL I would probably choose something rock solid like DynamoDB on AWS. That thing (mostly) scales by simply throwing money at it, on my last project that had tens of millions of users it worked very well, but it's definitely not cheap.
For my personal project I ended up going with PostgreSQL 9.4. The initial user experience is still as bad as I remember from years ago (after installing PostgreSQL on Ubuntu, neither the logged in user nor root have a default DB, can't even run psql, cannot create new DB's out of the box, and the tutorial(!) waxes on about "Architectural Fundamentals" instead of "Do x,y,z to install and insert a few rows of data").
With Postgres I'm able to have JSON type columns, where my unstructured documents are stored, as well as regular foreign keys, transactions and joins at the table level. So far I'm very pleased with how it's working out, I think it's a good middle ground between the flexibility of NoSQL and the reliability + querying power of SQL.
Note that this is a mainly packaging and entirely the maintainer's fault: They typically run the database under a "postgres" user, so you'll have to do "sudo -u postgres createdb" or whatever. PostgreSQL itself doesn't care; if you install it from source and start the postmaster process as yourself, then you'll have full access right away.
That said, Debian/Ubuntu packages typically don't set up a default environment for you as a convenience. It's debatable what it should do. Create a user and database for root? Postgres maps, by default, POSIX users to database users. If you run "apt-get install postgresql-server-9.4", who should it create database users for?
Also, I'm not sure you're fair to the documentation you're referencing, which seems entirely reasoanble to me. Section 1.2 of the 94 manual's tutorial, "Architural Fundamentals", is pretty important, and it's short. But if you skip it, you'll get to the next section, "Creating a database", which tells you what need, and the next one goes into the SQL stuff. Both sections work if you've installed it from source (or Homebrew, which also runs Postgres as yourself). But it would be silly to expect this documentation to tell you how to specifically do it on Ubuntu.
Which is fine, if you want to keep a high bar, but don't be surprised when people still think the product is "harder to use" than MongoDB or whatever in 2015. Blaming maintainers does nothing for the users, take ownership of the experience! If you want to be seen as approachable and easy to use, you have to actually target people new to PostgreSQL and not write the basic guide assuming you're compiling from source on Solaris or have a dedicated site DB administrator. The magic phrase "sudo -u postgres createdb" does not appear anywhere on postgresql.org that I can see, and as a experienced user you know that's not the end of it (can I use psql as my regular user after running it? No, of course not. There's many more entirely undocumented arcane incantations left!). I claim, it is in fact impossible to get up an running with no previous knowledge if all you have access to is the postgres site. Thankfully there's Stackoverflow, so at least some users are still getting through the gauntlet.
Sorry for the rant. I get a bit frustrated when I see a great project that I love dropping users through a bad onboarding experience (I know, contributions welcome...)
Just for reference, check out: https://docs.mongodb.org/manual/tutorial/install-mongodb-on-... https://docs.mongodb.org/getting-started/node/ In fact, you get different sets of documentations for the whole matrix of OS * ENV (Shell, Node, Python, C++, Java, C#). When the docs have their target audience down to a T ("Why yes, I AM a C++ developer on OS X! This looks like the perfect fit!"), it's easy to see why they're so popular.
Kidding aside, I suspect with a little discipline, one could design a PG DB that could be ported to Oracle (Exadata???) should the need, and budget ($$$$$), for that sort of scaling arise. Cheap and safe now, Expensive and safe later (if needed)
In theory there's no reason why we shouldn't be able to support a nice transactions API in the client drivers too, I just haven't gotten around to it yet.
In the ideal MongoDB implementation, an "order" would be a document of its own, and all the other parts would be attributes or nested structures. So you only really need a transaction for the document itself. Other documents could be inserted/updated at the same time without creating a conflict. That's the theory, at least. Martin Fowler has a good Youtube on "Introduction to NoSQL" that I sometimes show to my students: https://youtu.be/qI_g07C_Q5I
The other thing about NoSQL is that it's often used for write-once, then read-only applications. Twitter, Facebook, or Instagram would be good examples. When 1% of your queries are INSERTs and 99% are SELECTS (with UPDATE and DELETE almost never occurring), you really don't run as much risk of anomalies. I would not recommend NoSQL for something like a banking application where you're doing lots of updates and need to guarantee consistency.