You don't pick your storage layer based on perceived ease of devops, you pick it based on how well it accomplishes the needs of your workload. You pick it because it fits well in your architecture. If you're worried about scale before you need to scale, you're wasting thought cycles and probably capital. Worry first about getting people to give a shit about your product, and then move on to scale when the time comes.

You pick the database based on the characteristics that are important to your business. If you're cash/resource strapped than ease of operation will be important. If you're ingesting data at high rates from day one then scalability will be important. There are plenty of cases where MongoDB is the right choice from day one and plenty of cases where it isn't.

Who are you to lecture others on what is/is not important for their needs ?

If you are cash and resource strapped, then I would NOT recommend using MongoDB. Seriously, in terms of cash, Postgres can cost you nothing; if you are resource strapped - use Postgres, there are a heck of a lot more people who know it than MongoDB. If you can't setup replication, then IMO you have some seriously larger underlying problems with your startup.

Don't forget that a lot of people have realized that MongoDB is NOT a good fit for what they want to do. Then they have a resourcing problem - a big one.

MongoDB costs you nothing as well. And there are plenty of people who know MongoDB as well as 10gen who can provide official support if needed. It is quite a popular database you know.

And there are plenty of people who are switching away from PostgreSQL and other SQL databases to MongoDB. Again it is quite a popular database (hence the huge amounts of cash they seem to be easily raising).

psql has read only streaming slave replication with a hot standby failover, in the box.

Sure, but the base_backup process is painful enough to make it non-trivial. It's not like you can just bring up a new postgres instance, point it at an existing primary and say "catch up and start replicating".

Replication has certainly gotten much better in the past few years, though.

Yeah.. which takes 25 people and 45 days to set up /s

Mongodb literally has a 1-line command to add a replica set member and it works. This is still a huge advantage.

That's bs. With wal-e it took a few hours tops to set up a basic master-slave system from scratch if you didn't know what you're doing. I'd have to imagine it's easier now. With proper automation adding a replica should be as simple as booting a machine and running a script or two.

I don't care either way I just use RDS and don't worry about it. (You can add replicas in one click with RDS.)

I can't tell from the documentation whether wal-e supports non-cloud based synchronisation (https://github.com/wal-e/wal-e). There's no example listed there.

And if you think that is as simple as MongoDB's replica sets then frankly you are crazy.

Wal-E is a backup solution, and has something that Mongo doesn't it is capable of backing up every transaction and restoring the database state at any point in time. Because of its nature it can be used for replication.

Wal-E was written for use in cloud which has its own challenges, but if you want to run in your data center the closest thing is Swift in OpenStack.

As for Mongo, my company is currently using it, and I wouldn't say it's any easier especially when you try to use it in public cloud, when you no longer have guarantees that the instance you set up won't be terminated and recreated in different AZ. There are plenty of challenges.

I'm currently working on convincing other teams to drop using Mongo and instead make queries directly to Postgres which is our authoritative source of data. The idea was to simplify our infrastructure, and I was not expecting much difference in performance but oh boy. In all of my POCs that I did so far PG is beating Mongo that makes you feel sorry for it. Both in performance (you need to understand what you're doing and use right types, indices and queries) and data size (after moving, the data is much smaller so it no longer requires being distributed, and also the instances can be much smaller).

Mongo is perfectly capable of point in time restores... in fact Mongo corp has a SaaS that does this... I know of several who have done the same on their own. There's been plenty of work in side-channel events with Mongo's log shipping system.

Perhaps you can point to a relatively simple walkthrough to setup PostgreSQL with plv8 for replication (with an easy promotion of a slave to master), that doesn't take a commercial support license...

Everything I've seen seems incredibly convoluted and more difficult than say MS-SQL, MongoDB, RethinkDB, ElasticSearch or several other databases at data replication and spinning up new nodes, or handling a primary failure.

Also, most of my work with Mongo has performed very well, if your data is a good fit, which I will admit it isn't all a good fit. Honestly, I'd rather use pgsql with plv8 over mongo, or elasticsearch, or ms/azure-sql... The support costs and my time are important to me, and better spent working on architecture or development. If I can make an operations level decision that works well enough, or is easier to scale then the development time is almost a wash.

It's really not, the thing that makes a piece of software successful is not how many lines of bash it takes to "scale". It's how hard it is to need to scale. You're worried about the wrong thing.

Replication isn't about scaling, it's about HA. And MongoDB's replication is dead simple to setup. I am waiting for PGSQL to catch up in that regard, they are working on it and making good progress.

If you need scaling in MongoDB, you're looking at replica sets combined with sharding. Not all workloads, as you rightly point out, need to scale from the get-go, but there are an awful lot that need HA.

Thank you... This was kind of my point... I will note that if you are in a situation with very heavy read usage, then replication does give you scaling regarding that. Again, my use case was for a classifieds site, where roughly have the page views are search results.

Who said anything about scaling? I run simple low utilization services on a replica set because of high availability. Replication only provides secondary reads in terms of scaling and that's not the point. Actual scaling comes from sharding (partitioning of data).