Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jepsen Disputes MongoDB's Data Consistency Claims

infoq.com

Post reply on HN
Print view View original

271–280 of 416 posts

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#271

Post by pier25 »

kiwicopple wrote: post #152
jedberg wrote: 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…

We[1] have done 50+ conversations with developers this year (mostly indie and small startups). You’re right about the ease of use. The top reasons are - they don’t know why, it was just the one they learned/heard about first - there is a lot of tooling for it A lot of them even knew about the limitations of MongoDB but they still choose it. We concluded that other databases need to start prioritising usability; somet…

So Supabase is like Hasura for REST?

When are you launching?

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#272

Post by virgilp »

btown wrote: post #265
kyllo wrote: post #128

Earlier quoted context omitted.

I was floored by this comment yesterday from one of their Developer Relations people: > Did any of you actually read the article? We are passing the Jepsen test suite and it was back in 2017 already. So, no, MongoDB is not losing anything if you know what you are doing. https://twitter.com/MBeugnet/status/1253622755049734150?s=20 Can you imagine saying the phrase "if you know what you are doing," in public, to your u…

Generally speaking, there are many levels of “if you know what you are doing.” - The system warns about unsafe usage at either compile time or runtime, and you ignore at your peril. - The system does not warn, but official documentation is consistently verbose about what is required for safety. - Official documentation isn’t consistently helpful and can be downright dangerous, but the community picks up the slack. -…

The problem is that if you know what you are doing (I.e. you configure MongoDB to be safe) you may lose all reason to use it (no longer has the same performance, of course)

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#273

Post by erulabs »

isatty wrote: post #208
erulabs wrote: post #186

I wonder if I'm the only sysadmin in the world who doesn't hate MongoDB. Yes, I wouldn't use it for new projects, and yes, I wish RethinkDB had taken its place, but it's not as horrible as people seem to think. Default configuration... If it weren't for RDS' doing PG-bouncer-style connection management, 95% of production postgres instances would probably fail. It innodb_buffer_pool_size wasn't set properly, plenty of…

> You can learn a lot about a developer by asking "What do you think about Mongo, JavaScript, or PHP", and if their response isn't a shrug, they're probably more concerned with what editor is correct than if the product they're building is useful. It's an exceptional filter to reject zealots and find pragmatists. Sure, if they’re being rude about it. A developer saying that it will not fit the use case or talking abo…

Yes, I couldn't agree more. Didn't mean people can't have opinions of course - just that they shouldn't be scoffing/laughing at tools - to me its a particularly red flag. Not wanting to use a particular tool is totally fine!

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#274

Post by takeda »

Carpetsmoker wrote: post #224
takeda wrote: post #18

Earlier quoted context omitted.

Agree, and the "Mongo and Jepsen" page isn't targeting distributed systems experts, most of them know to stay away, because even if there are things that mongo does right, other systems do it better.

What other systems would you recommend?

I don't consider myself an expert in that area. Just someone who learned a lot from Kyle's articles.

Based on this, my understanding is: most of the time you want a relational database. If a relational database becomes a bottleneck for certain data, and you don't want to do typical scaling solutions for relational data, then you need to know what you'll trade for the higher performance. Based on what you trade, you then decide what kind of data store you will use.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#276

Post by neeleshs »

vosper wrote: post #262
squeaky-clean wrote: post #133

Earlier quoted context omitted.

I like it, but I don't really really chime in on threads where it's mostly Mongo bashing and jokes, and I'm guessing others who like MongoDB do the same. But I'd think MongoDB the company increasing in revenue isn't totally related to the quality of MongoDB the database. In fact a lot of their products seem to be targeting the "I don't want to learn how to set it up and understand indexes" crowd.

Which is funny because one of the things hosted Mongo will do is constantly send you automated emails suggesting that you should create indexes (for tables that MySQL or Postgres would laugh at)

Sends emails when scanned vs returned record ratio is greater than a threshold. Not quite sure how something like this would be different for MySQL/postgres. If an index is missing for you query pattern, wouldn't you create an index in MySQL/postgres?

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#277

Post by kiwicopple »

pier25 wrote: post #271
kiwicopple wrote: post #152

Earlier quoted context omitted.

We[1] have done 50+ conversations with developers this year (mostly indie and small startups). You’re right about the ease of use. The top reasons are - they don’t know why, it was just the one they learned/heard about first - there is a lot of tooling for it A lot of them even knew about the limitations of MongoDB but they still choose it. We concluded that other databases need to start prioritising usability; somet…

So Supabase is like Hasura for REST? When are you launching?

Very similar - our realtime is done a bit differently (we use the WAL rather than triggers), and we plan to use Postgres' RLS rather than a custom Auth system.

> When are you launching?

We're in alpha now - https://app.supabase.io (desktop only)

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#278

Post by kvz »

Carpetsmoker wrote: post #224
takeda wrote: post #18

Earlier quoted context omitted.

Agree, and the "Mongo and Jepsen" page isn't targeting distributed systems experts, most of them know to stay away, because even if there are things that mongo does right, other systems do it better.

What other systems would you recommend?

FoundationDB

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#279

Post by kstrauser »

benibela wrote: post #109
thomascgalvin wrote: post #53

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…

What if they prefer an XML database (like basex, exist, marklogic)?

We ask them politely, yet firmly, to leave.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#280

Post by Jare »

collyw wrote: post #82
Jare wrote: post #51

Earlier quoted context omitted.

Reading past marketing blurbs and using products for the things they are designed is part of any engineer's job. I was irritated by MongoDB's claims and defaults, but that didn't stop us from putting it in production. We used it from 2012 to 2016 (their most infamous years?), and for our use cases, scale, size+expertise, and feature set, it was a perfect match. In our case, durability was a smaller concern by design…

>In our case, durability was a smaller concern by design (lots of write-only data, lots of ephemeral data), I assume that you mean write once data. If you mean write only you might as well use /dev/null.

Most backups are never actually read / used after writing but /dev/null is not a good substitute for them.

[Edit] in case I wasn't clear: Imagine data that is written and rewritten and overwritten before it gets read; a user that never returns to your product - his state data was written but will never be read. That sort of thing.

Post reply on HN