Live data from Hacker News

Jepsen Disputes MongoDB's Data Consistency Claims

infoq.com

61–70 of 416 posts

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#61
post #46

From the jepsen report: """ Curiously, MongoDB omitted any mention of these findings in their MongoDB and Jepsen page. Instead, that page discusses only passing results, makes no mention of read or write concern, buries the actual report in a footnote, and goes on to claim: > MongoDB offers among the strongest data consistency, correctness, and safety guarantees of any database available today. We encourage MongoDB t…

MySQL and PG are not truly consistent per default, they don't fsync every writes. MongoDB explains that pretty well: https://www.mongodb.com/faq and https://docs.mongodb.com/manual/core/causal-consistency-read...

> MySQL and PG are not truly consistent per default, they don't fsync every writes.

Postgres most certainly does fsync by default.

It's tru, you can disable it, but there is a big warning about "may corrupt your database" in the config file.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#62

Earlier quoted context omitted.

Why not use PostgreSQL instead? It supports a JSON document data type natively. It also has exceptional stewardship as an open source project. Mongo should never be a first choice, but a last choice for edge cases.

> Why not use PostgreSQL instead? It supports a JSON document data type natively. Yes, that's the thing, it's just a field type. It's not really that different than dumping your JSON in a TEXT column. MongoDB is fun because it's truly JSON - BSON - so you don't have to run migrations, you can store complex documents, and have a more object oriented way of storing your data than SQL.

It's completely different than dumping json into a text field...

Read the docs, you can do a lot of fancy JSON stuff in plain ol' Postgres. It's really powerful and guarantees your data.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#63
post #29

MongoDB started life as a database designed for speed and ease of use over durability. That's not a good look for a database. People have told me that they have since changed, but the evidence is overwhelmingly and repeatedly against them. They seem to have been successful on marketing alone. Or people care more about speed and ease of use than durability, and my assumptions about what people want in a database are j…

> MongoDB started life as a database designed for speed and ease of use over durability. That's not a good look for a database. I think it depends. One could say the same about Redis, but it's wildly successful and people love it. The difference is now they are advertised. Redis makes no claims to be anything other than what it is - a fast in-memory database that has some persistence capability but isn't meant to be…

Yes. What I love most about Redis is that the fundamental tradeoffs of the algorithms it's built on are surfaced up through the interface, and made very plain in the documentation.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#64

In the circles I run in, MongoDB is regarded as a joke and the company behind it as basically duplicitous. For example, they still list Facebook as their first user of MongoDB on their website, for example, but there is no MongoDB use in Facebook hasn't been for years (it came in only via a startup acquisition). I had the misfortune to use MongoDB at a previous job. The replication protocol wasn't atomic. You would f…

There was a time when I advocated for MongoDB with the usual caveats. The ability to easily store and index complex data was of great value. And then in 2015 October, within a week of each other, SQLite and MySQL both learned how to index on expressions and store JSON (SQLite 3.9 2015-10-14, MySQL 5.7 2015-10-21). PostgreSQL added jsonb the year prior in 9.4. At that moment the value of MongoDB for me diminished greatly.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#65
post #44

MongoDB's big problem is that their present user base does not want the problems fixed, particularly at default settings, because it would mean going slower. Their users are self-selected as not caring much about integrity and durability. There are lots of applications where those qualities are just not very important, but speed is. People with such applications do need help with data management, and have money to sp…

If they only cared about performance then they would've left the write concern defaults to not acknowledge writes either locally or within a replica set. Or just read from the nearest replica and don't worry about potential consistency issues.

Also this isn't 2011. MongoDB is not a competitor to Oracle and never really has been by people that knew that a DocumentDB was not usable as a SQL one. It's other SQL databases that are the real competitors e.g. Snowflake, Redshift are.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#66

You can tell a lot about a developer by their preferred database. * Mongo: I like things easy, even if easy is dangerous. I probably write Javascript exclusively * MySQL: I don't like to rock the boat, and MySQL is available everywhere * PostgreSQL: I'm not afraid of the command line * H2: My company can't afford a database admin, so I embedded the database in our application (I have actually done this) * SQLite: I'm…

And you can tell a lot about a developer when they post comments like this. Almost none of is remotely accurate e.g. RabbitMQ isn't even a database.

LOL

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#67
post #29

MongoDB started life as a database designed for speed and ease of use over durability. That's not a good look for a database. People have told me that they have since changed, but the evidence is overwhelmingly and repeatedly against them. They seem to have been successful on marketing alone. Or people care more about speed and ease of use than durability, and my assumptions about what people want in a database are j…

I used it effectively to denormalize and combine some data from other services... sort of like a 2nd level, queryable cache. Worked very well for my needs. This was 7-8 yrs ago.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#68

You can tell a lot about a developer by their preferred database. * Mongo: I like things easy, even if easy is dangerous. I probably write Javascript exclusively * MySQL: I don't like to rock the boat, and MySQL is available everywhere * PostgreSQL: I'm not afraid of the command line * H2: My company can't afford a database admin, so I embedded the database in our application (I have actually done this) * SQLite: I'm…

And you can tell a lot about a developer when they post comments like this. Almost none of is remotely accurate e.g. RabbitMQ isn't even a database.

[deleted]

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#69

In the circles I run in, MongoDB is regarded as a joke and the company behind it as basically duplicitous. For example, they still list Facebook as their first user of MongoDB on their website, for example, but there is no MongoDB use in Facebook hasn't been for years (it came in only via a startup acquisition). I had the misfortune to use MongoDB at a previous job. The replication protocol wasn't atomic. You would f…

I run in two circles: the one you mention, but also the other: I have gotten pushback from people (usually devs at clients of mine) for saying it’s lunacy to run a real, actual business on Mongo. (This has always happened from orgs with You’d be astounded how common it is at so-called “enterprise” startups. It blew my mind.

A lot of people simply never went through the LAMP stack days and have little/no experience with real databases like Postgres (or even MySQL). It’s disheartening.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#70

You can tell a lot about a developer by their preferred database. * Mongo: I like things easy, even if easy is dangerous. I probably write Javascript exclusively * MySQL: I don't like to rock the boat, and MySQL is available everywhere * PostgreSQL: I'm not afraid of the command line * H2: My company can't afford a database admin, so I embedded the database in our application (I have actually done this) * SQLite: I'm…

As someone who chose MySQL and provides direction to developers who really like Postgres, and who also uses Postgres for fun, I do find myself having to both defend MySQL as a prudent option and convince them that I know anything at all about Postgres or computer science. :)
Post reply on HN