Live data from Hacker News

Failing with MongoDB

blog.schmichael.com

41–50 of 128 posts

Re: Failing with MongoDB

#41
post #2

Why is a database that fails so easily and most of the time even loses data so popular? Is it really all just a huge marketing budget?

There are tons of reasons for that. Let me pull some of them from my butt: Reason #1: Devs aren't Ops. Reason #2: Devs need something new on their resume. Reason #3: Certain type of Devs would read blogs and get excited and skipping scientific mumbo-jumbo and directly take the blogs as _the_ source of truth. Reason #4: It's easy to bootstrap (schemaless, etc) your weekend project. Dealing with DB apparently is tediou…

Well here's a fuck you back from a dev: my time is finite and everyone wants a piece of it; If I can save an hour a day by never having to think about my database? If I can shave a week or two of labor off a project?

It's really easy to work with. This is why people keep using it.

Re: Failing with MongoDB

#43
post #2

Why is a database that fails so easily and most of the time even loses data so popular? Is it really all just a huge marketing budget?

I have been asking that too and I concluded that it is due to dishonest marketing. Up until a couple of months ago they basically shipped a database product with disabled singe server durability. That fact should have been written in bright flashing red letter warning on their front page, it wasn't. So it made for very fast benchmarks, because everyone benchmarks for speed, not many benchmark for failure.

Re: Failing with MongoDB

#44
post #6

Earlier quoted context omitted.

There are tons of reasons for that. Let me pull some of them from my butt: Reason #1: Devs aren't Ops. Reason #2: Devs need something new on their resume. Reason #3: Certain type of Devs would read blogs and get excited and skipping scientific mumbo-jumbo and directly take the blogs as _the_ source of truth. Reason #4: It's easy to bootstrap (schemaless, etc) your weekend project. Dealing with DB apparently is tediou…

Right there with you. The excuses I hear for not wanting to use a good 'ole RDBMS just does not make sense to me sometimes. CREATE TABLE too hard? Time consuming? Difficult? Those who do not study the history of databases are doomed to repeat it. Soon we'll add back row-level write locks, transaction logging, schemas, multiple indexes and one day they wake up with MongoSQL.

You say that like it's a failure on the devs' part, but that's kind of like blaming regular users for not switching to Linux because they don't like editing network configuration files.* It's masking the problem that there are real developer-friendliness issues with the existing databases. And taunting users will not get them to switch back.

* but then Linux distros get network autoconfiguration and suddenly it's obvious that it was the right solution all along.

Re: Failing with MongoDB

#45

Earlier quoted context omitted.

There are tons of reasons for that. Let me pull some of them from my butt: Reason #1: Devs aren't Ops. Reason #2: Devs need something new on their resume. Reason #3: Certain type of Devs would read blogs and get excited and skipping scientific mumbo-jumbo and directly take the blogs as _the_ source of truth. Reason #4: It's easy to bootstrap (schemaless, etc) your weekend project. Dealing with DB apparently is tediou…

Well here's a fuck you back from a dev: my time is finite and everyone wants a piece of it; If I can save an hour a day by never having to think about my database? If I can shave a week or two of labor off a project? It's really easy to work with. This is why people keep using it.

What about all the time you'll waste debugging your app because you can't make good assumptions about the structure of your data?

Re: Failing with MongoDB

#46
post #3
post #2

Why is a database that fails so easily and most of the time even loses data so popular? Is it really all just a huge marketing budget?

The the data model contributes to it's popularity. A document store with indexes on document fields is very convenient for several types of applications.

You can do exactly the same document store with indexes on any RDBMS.

Re: Failing with MongoDB

#47
post #37

Earlier quoted context omitted.

Sadly, it seems that "give them free crap and then charge for fixes" is a very common business model in the open source world.

I am really happy that this does not exist in the PostgreSQL community despite many of the core developers being consultants who live off solving their clients' problems with PostgreSQL. Maybe this is because it is a community project with no single company in control of it.

Maybe this is because it is a community project with no single company in control of it.

Yes. In an organization like Postgresql, someone's contribution is measured by how much they contribute to the code. In an organization like Mysql, someone's contribution is measured by how much they contribute to the bottom line.

Re: Failing with MongoDB

#48

Earlier quoted context omitted.

Sadly, it seems that "give them free crap and then charge for fixes" is a very common business model in the open source world.

Better than asking for big pile of money and give back crap and charge way more for fixes isn't it? :)

Yes. But I think asking happy users to donate ultimately produces better code than asking unhappy users to pay for support.

Re: Failing with MongoDB

#50
post #44
post #6

Earlier quoted context omitted.

Right there with you. The excuses I hear for not wanting to use a good 'ole RDBMS just does not make sense to me sometimes. CREATE TABLE too hard? Time consuming? Difficult? Those who do not study the history of databases are doomed to repeat it. Soon we'll add back row-level write locks, transaction logging, schemas, multiple indexes and one day they wake up with MongoSQL.

You say that like it's a failure on the devs' part, but that's kind of like blaming regular users for not switching to Linux because they don't like editing network configuration files.* It's masking the problem that there are real developer-friendliness issues with the existing databases. And taunting users will not get them to switch back. * but then Linux distros get network autoconfiguration and suddenly it's obv…

Every major RDBMS has both command-line and GUI interfaces to create and change schemas. What exactly is missing in the dev-friendlyness department?
Post reply on HN