Take some database courses, learn about transactions and isolation models, maybe some do some distributed systems courses, learn about agreement protocols, failure models, recovery models....

Some may think the OP is joking.

https://www.youtube.com/watch?v=nzjIP6O4kEo

Whats the issue with that video? (I can't watch a full 27 min presentation right now)

Why do they even have a Ruby driver? Isn't FFI a thing in ruby?

A pure Ruby driver makes it available on JRuby, which doesn't handle the FFI as well.

scoff all you want, that's a better explanation of threading and the dangers entailed than I got in a whole semester of my undergrad. there's an art in explaining something complex simply.

I'm sorry, but that talk is depressing. It starts with a grand statement that there's no such thing as threadsafe ruby code, and as a demonstration of that, it shows multithreaded code written by someone who had apparently never heard of synchronization primitives. It then goes on to explain how to use synchronization primitives to make your code threadsafe. It's like watching someone discover error handling for the first time.

> who had apparently never heard of synchronization primitives.

i think that's the nub of our difference of opinion. i saw that as a ruse, i don't genuinely believe that the presenter never heard of them.

Exactly. Thank you.

OK, I laughed.

It's going to take a lot of marketing people to convince people to pay for something they can now get for free via PostgreSQL.

If that were true, there would be an order of magnitude fewer commercial database systems on the market.

It's true, and soon there won't be.

Well, I might be downvoted to hell like the other poster, but from where I sit thats a possibility far out into the future.

I think you are thinking there will be an objective reckoning of features/performance/reliability and somehow since OSS wins all of those they will choose it, and as far as I am concerned, thats not actually why they choose their database in the first place.

A million b2b apps are developed on sql server because visual studio/microsoft makes that easy for their .net stack, and oracle sells to executives or other manager types and gets shoehorned into projects or set as a requirement before smart people get involved ALL THE TIME.

A lot of it still comes down to enterprise pricing, support, integration, and name recognition.

This is true. Also, vendorware that's written to Oracle.

However, I am thankful my own bosses can count, and went "WHAT" at the last Oracle bill.

So we're actively seeking to move our own stuff from 'Orrible to PG, and to get rid of the vendorware depending on Oracle.

We just got AppDynamics in (ridiculously versatile and useful monitoring). Speaking to the AD sales engineer, he said a lot of their Oracle-using customers are eyeing up PG similarly.

an opinion that has been touted since the 90's. still just as wrong.

PostgreSQL does not have in the box master-slave replication with automatic failover and promotion. This is probably one of the biggest issues in where I would choose MongoDB over PostgreSQL, sharding is another.

I like PostgreSQL, and plv8 looks incredibly cool... when replication and promotion are in the box (not needing enterprise or other complex addons), It'd be my first choice for most situations.

(edited comment to make it less snarky)

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).

Hire, Hire and Hire. I suspect their infrastructure costs are very high too.

One challenge that companies find as they try to scale is they have to add a lot of Sales and Marketing costs well before they receive any revenue, so there's a cost bump despite low growth in engineering. This is compounded if there's a professional services component.

They should instead fire some of their technical decision makers and use the $100M as compensation for pain and suffering for early adopters. Choosing MongoDB for a project was one of the biggest failures in my career.

What do you mean by infrastructure costs?

I'm assuming just their test farm dwarfs most regular deployments.

They have a huge test matrix. Sharding tests, performance tests, and large data tests probably take a long time.

You can see their test matrix here: https://mci.10gen.com/

and the driver tests here: https://jenkins.mongodb.com/

Also they run https://mms.mongodb.com/ which does backup and monitoring

Even $1M buys a lot of test equipment.

They have MongoMMS which has 2 datacenters and provides backup and monitoring services for Mongo clients

They'll probably spend it on marketing MongoDB as a replacement to relational databases. Brainwashing isn't cheap.

I don't know why you're being downvoted, that seems to be their MO.

Some part of it certainly goes into MongoDB development. It still sucks, but every new version has a ton of major improvements. I may give it another try once 2.8 is released.

Been using MongoDB for searches on ClassicCars.com for about 3 years with minimal issues.

Although the next generation is moving to ElasticSearch, we haven't had issues with our use of MongoDB (which is a very good use case for it).

Sales & Marketing - or as Zed Shaw likes to put it "steaks and strippers"[0]

[0] - http://vimeo.com/2723800