Relational databases are safe out of the box, but it is not their unique capability. Most other NoSQL stores are safe out of the box, too, being at the same time faster and easier to scale than RDBMSes. It is only Mongo which did it differently, so please don't extrapolate that bad experience to all NoSQL.
A back of the envelope calculation. Assume each shipment brings in $0.10 in profit to his company. Suppose at some point he needs to scale up to 100,000 shipments/day. His revenue is now $10,000/day.
A "Performance One" Rackspace server costs $1250/month and Rackspace isn't known for being cheap. A Hetzner box with all the things added (12TB HD, 2.4TB SSD HD, 384GB RAM) costs 831 Euro/Month.
Not if your application is still on development.
100k+ rows? Not complicated. Try with 23M rows.
Nobody would risk migrating that table.
This has been happening for decades in the RDBMS world – even the ultra-conservative Oracle admins I've worked with were willing to come of out in-place retirement long enough to do something like that.
How many DBs do you have? Testing (usually local), staging, production? For how many sites?
It works the same, if row['new_field'] do_something() else do_something_else()
You have unit tests to make sure it works.
And if it was so safer and easy to do it PostgreSQL wouldn't have added the json field.
In your experience, perhaps, but that's reversed in many other places.
As for everything else your point is only accurate if you assume that migrations are done by hand. If use a migration library it's impossible to forget to apply a migration to a database so there's no problem working with copies or even forks of databases.
> And if it was so safer and easy to do it PostgreSQL wouldn't have added the json field.
You're implying causation incorrectly: hstore and JSON are useful for cases where you explicitly do not want schema enforcement or can't afford the performance impact of normalization. This is not saying that migrations are hard, merely that not all problems have the same best solution.
(Of course, not only migration issues, but any code issues as well)
People migrate tables a lot bigger than 23M rows all the time. On MySQL, even, though it's an offline task there.
> The advantages of schemaless documents are priceless. Not having to migrate is just one of the perks. Our schemas were largely in the form of Orders (having many) Shipments (going_from) ShipPoint (to) ShipPoint
You say priceless. I don't think it means what you think it means. A migration is costly but also pretty rare. I migrate PostgreSQL with 100k+ rows as a matter of routine, it's over before you know it. The schema you are using (orders have many shipments going from point to point) are easily expressed in a relational schema and once defined would hardly ever need to change, if at all during the lifetime of the application. So what if I need to add a column here or there. It won't matter at all. Do you have more than 100 million documents in MongoDB? I guess you don't. Even if you do, relational has that covered too.
> This doesn’t always have to be the case, though it significantly contributes to Mongodb’s fast writes.
What you are saying is that I need to change MongoDB in order to make it safe. Relational database are safe out of the box, no change necessary.
> We add a lot of Notes to each shipment [...] it doesn’t critically affect the business workflows of the application.
Say what?
You're fine with data, even notes, being lost? That is completely acceptable to you? I guess this is what shocks me most. You kids think it's normal to lose data, and consider storing a note to be optional or something. It baffles me. If a note is optional, why have it in the first place?
> They do but since most of the stuff is memory mapped
Translates to: you need to have your data in RAM. This does not scale at all. It doesn't even begin to scale to the level where MySQL was. TEN years ago.
> Here is a simplified snapshot
What follows is a class that is 236 lines long. Two hundred and thirty-six lines long. Dear sir, if this is your simplified code I fear what your actual production code looks like. If you committed that to one of my repos we would have a very serious talk. Also you would do this exactly once during your career at my company.
> I haven’t even touched upon the replication and sharding features that Mongodb offers which I will reserve for another post.
Which every relational store also offers.
> To summarise I feel Mongodb is awesome
Why is it awesome? You have only shown me why it is horrible. I have seen nothing that is awesome. Optional data persistence, needs huge amounts of RAM, complex application level code to deal with reports, this is all stuff that you can do better, faster and more reliable with a relational solution.