10 ms·

I don't get it. I don't get it. I don't get it. 1) Mongo is not better than Postgresql JSONB and other Postgresql features, especially in 10. 2) There was NEVE

I don't get it. I don't get it. I don't get it. 1) Mongo is not better than Postgresql JSONB and other Postgresql features, especially in 10. 2) There was NEVER a Mongo cluster management tool named Sheriff Bart! It litterally sells itself: Mongo Loves Sheriff Bart. 3) ArangoDB is able to provide many of the Mongo features with some ACID compliance and a better graph solution. It even has joins. I get that people use documents to avoid joins, but really. You still want them.

redwood 9y ago
This is like saying "The iPhone is not better than Android". There is room for multiple offerings with different strengths and paths to market appealing to different types of users.
- virmundi 9y ago
  I upvoted you. You raise a good example. To the same simile, if you care about use, freedom and reasonableness, you'd pick Android. So too anything other than Mongo. That's what I don't get, why would anyone want to invest in Mongo? I say that as a Mongo certified develop (best way to learn at the time).
  - redwood 9y ago
    Speculating, amongst the "Android" options there are four categories: - There are the expensive legacy relational solutions (these are on a long slow death). - There are small open source and sometimes even closed source projects that are either going to be dead or gobbled up; or at least far too many people will fear they will which will prevent adoption. - There are cloud-native lock-in solutions. - There are well-established large community open source projects that stay alive because there's enough stakeholders but they don't have strong commercial backers. All of these categories are a surprisingly interesting market opportunity for a disruptive commercially backed more vertically integrated open source player to target.
arrty88 9y ago
Mongo is quick and dirty. If you're writing NodeJS, chances are you don't care about `what's best`.
- virmundi 9y ago
  You can do that with Arango. Equally quick. Equally dirty. Doesn't require a prod version with 3 nodes just to make sure, hand to God, no data is lost.
  - krisdol 9y ago
    I've literally never heard of Arango before reading these comments. That might have something to do with people not using it.
    - don71 9y ago
      Or maybe it's related to fact that it's pretty young.
    - virmundi 9y ago
      It probably has to do with being German. The US produces alot of tech that the rest of the world knows, due to PR. Germany. Well, they move quietly. Then BAM! ArangoDB in Poland!
- bsg75 9y ago
  So are you implying Node developers are fine with half-assed solutions? They might disagree.
  - brokenpromise 9y ago
    They might disagree, but that doesn't mean they're right.
- rawnlq 9y ago
  For fast prototyping, it's pretty hard to beat a NodeJS stack. A lot of modern web dev are one-man-shows. When you're just one developer doing frontend and backend, you don't really have time to care about database migrations or designing schemas. You really just want to duct tape enough pieces together to get your app out the door. Caring about schema design, database migration, or even code correctness doesn't really help with this. Mongo in comparison has no learning curve, crazy number of pre-integrated libraries, and works well enough at low scale. This might sound like cancer to corporate devs but the tradeoff does make sense for individuals/demos/startups. A illustrative case study: https://medium.com/unboxd/how-i-built-an-app-with-500-000-users-in-5-days-on-a-100-server-77deeb238e83 https://medium.com/unboxd/how-i-built-an-app-with-500-000-us...
elvinyung 9y ago
It's a bad strawman to say that PostgreSQL is ACID and MongoDB isn't. Here's the thing: even PostgreSQL isn't ACID when you throw replicas into the mix. And PostgreSQL as it stands "doesn't scale" past a single box, not if you want to do (most kinds of) replication or sharding. The impression I get is that at scale, you don't really "need joins" and multi-table ACID for the kind of workload that MongoDB is targeting, i.e. massive throughput embarrassingly-parallel low-latency OLTP short requests that do point queries and point writes. It seems to be atomic, consistent and durable enough for that [1]. For analytical queries that really do need expressive SQL features, you generally wouldn't want to run them on the same database anyways, not when you're "at scale" and your seven-way join could impact other request latencies. You export it to Redshift or HDFS/S3, and do all the reporting/BI/analytics on it. [1] https://jepsen.io/analyses/mongodb-3-4-0-rc3 https://jepsen.io/analyses/mongodb-3-4-0-rc3
- dustingetz 9y ago
  First of all https://en.wikipedia.org/wiki/Consistency_(database_systems) https://en.wikipedia.org/wiki/Consistency_(database_systems) There is no strawman, postgres is literally acid and mongo literally isn't, full stop. Second of all, Mongo marketing and ecosystem is foremost about making dashboard crud apps easy with not a lot of engineering. dashboards are not about point reads. Whether or not mongo is engineered for it, this is what the customers are using it for. Third, I just wrote a proposal today for a client on Mongo, not at scale, who experiences silent database failures due to lack of acid. they only noticed because Mongo sometimes tells them there are -2 people left in the room. Nobody at scale uses mongo because somewhere along the way you spend your giant bags of scale-money to hire a real engineering team to solve the silent errors and failwhales you've been suffering by migrating to an architecture that actually lets you reason about failure a little better than "it looks like something bad happened but we have no idea when how or why"
  - mayank 9y ago
    Please read OP's comment. Postgres is not ACID with read replicas. The replication lag yields eventual consistency.
curiousDog 9y ago
Also, what does Mongodb offer that other NoSQL stores like DynamoDb, Bigtable, Azure Cosmos DB etc don't? I'm genuinely curious. I believe there's ACID support on these as well (Probably on by default on Dynamodb).
- redwood 9y ago
  Those are each cloud native (lock-in solutions) rather than software, let alone open source software... That's a huge difference.
- tlarkworthy 9y ago
  Latency

redwood 9y ago

This is like saying "The iPhone is not better than Android". There is room for multiple offerings with different strengths and paths to market appealing to different types of users.

virmundi 9y ago
I upvoted you. You raise a good example. To the same simile, if you care about use, freedom and reasonableness, you'd pick Android. So too anything other than Mongo. That's what I don't get, why would anyone want to invest in Mongo? I say that as a Mongo certified develop (best way to learn at the time).
- redwood 9y ago
  Speculating, amongst the "Android" options there are four categories: - There are the expensive legacy relational solutions (these are on a long slow death). - There are small open source and sometimes even closed source projects that are either going to be dead or gobbled up; or at least far too many people will fear they will which will prevent adoption. - There are cloud-native lock-in solutions. - There are well-established large community open source projects that stay alive because there's enough stakeholders but they don't have strong commercial backers. All of these categories are a surprisingly interesting market opportunity for a disruptive commercially backed more vertically integrated open source player to target.

arrty88 9y ago

Mongo is quick and dirty. If you're writing NodeJS, chances are you don't care about `what's best`.

virmundi 9y ago
You can do that with Arango. Equally quick. Equally dirty. Doesn't require a prod version with 3 nodes just to make sure, hand to God, no data is lost.
- krisdol 9y ago
  I've literally never heard of Arango before reading these comments. That might have something to do with people not using it.
  - don71 9y ago
    Or maybe it's related to fact that it's pretty young.
  - virmundi 9y ago
    It probably has to do with being German. The US produces alot of tech that the rest of the world knows, due to PR. Germany. Well, they move quietly. Then BAM! ArangoDB in Poland!
bsg75 9y ago
So are you implying Node developers are fine with half-assed solutions? They might disagree.
- brokenpromise 9y ago
  They might disagree, but that doesn't mean they're right.
rawnlq 9y ago
For fast prototyping, it's pretty hard to beat a NodeJS stack. A lot of modern web dev are one-man-shows. When you're just one developer doing frontend and backend, you don't really have time to care about database migrations or designing schemas. You really just want to duct tape enough pieces together to get your app out the door. Caring about schema design, database migration, or even code correctness doesn't really help with this. Mongo in comparison has no learning curve, crazy number of pre-integrated libraries, and works well enough at low scale. This might sound like cancer to corporate devs but the tradeoff does make sense for individuals/demos/startups. A illustrative case study: https://medium.com/unboxd/how-i-built-an-app-with-500-000-users-in-5-days-on-a-100-server-77deeb238e83 https://medium.com/unboxd/how-i-built-an-app-with-500-000-us...

elvinyung 9y ago

It's a bad strawman to say that PostgreSQL is ACID and MongoDB isn't. Here's the thing: even PostgreSQL isn't ACID when you throw replicas into the mix. And PostgreSQL as it stands "doesn't scale" past a single box, not if you want to do (most kinds of) replication or sharding. The impression I get is that at scale, you don't really "need joins" and multi-table ACID for the kind of workload that MongoDB is targeting, i.e. massive throughput embarrassingly-parallel low-latency OLTP short requests that do point queries and point writes. It seems to be atomic, consistent and durable enough for that [1]. For analytical queries that really do need expressive SQL features, you generally wouldn't want to run them on the same database anyways, not when you're "at scale" and your seven-way join could impact other request latencies. You export it to Redshift or HDFS/S3, and do all the reporting/BI/analytics on it. [1] https://jepsen.io/analyses/mongodb-3-4-0-rc3 https://jepsen.io/analyses/mongodb-3-4-0-rc3

dustingetz 9y ago
First of all https://en.wikipedia.org/wiki/Consistency_(database_systems) https://en.wikipedia.org/wiki/Consistency_(database_systems) There is no strawman, postgres is literally acid and mongo literally isn't, full stop. Second of all, Mongo marketing and ecosystem is foremost about making dashboard crud apps easy with not a lot of engineering. dashboards are not about point reads. Whether or not mongo is engineered for it, this is what the customers are using it for. Third, I just wrote a proposal today for a client on Mongo, not at scale, who experiences silent database failures due to lack of acid. they only noticed because Mongo sometimes tells them there are -2 people left in the room. Nobody at scale uses mongo because somewhere along the way you spend your giant bags of scale-money to hire a real engineering team to solve the silent errors and failwhales you've been suffering by migrating to an architecture that actually lets you reason about failure a little better than "it looks like something bad happened but we have no idea when how or why"
- mayank 9y ago
  Please read OP's comment. Postgres is not ACID with read replicas. The replication lag yields eventual consistency.

curiousDog 9y ago

Also, what does Mongodb offer that other NoSQL stores like DynamoDb, Bigtable, Azure Cosmos DB etc don't? I'm genuinely curious. I believe there's ACID support on these as well (Probably on by default on Dynamodb).

redwood 9y ago
Those are each cloud native (lock-in solutions) rather than software, let alone open source software... That's a huge difference.
tlarkworthy 9y ago
Latency