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.
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).
- 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.
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.
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"
Repeat after me: PostgreSQL isn't ACID in a distributed system.
PostgreSQL isn't actually ACID when your database is multiple machines. PostgreSQL isn't actually ACID when you set up your first read replica on RDS. PostgreSQL isn't actually ACID when you use streaming or logical replication. PostgreSQL isn't actually ACID when you start sharding your users table. PostgreSQL isn't actually ACID in a world in which people need to scale out from one big box. It's eventually consistent, which is even less than I can say about MongoDB on a single-document level.
Personally, PostgreSQL is my favorite DBMS. It's well-engineered, extremely mature, and has lots of great features. Working seamlessly and providing strong guarantees outside a single box, unfortunately, isn't one of them. Not yet, at least.
To address the rest of your points: those people are using MongoDB wrong. PostgreSQL basically stops working well too, once you start mixing transaction processing and business reporting and BI in the same box at scale.
If you're going to claim that MongoDB is bad because it's not ACID or somesuch, you better hold PostgreSQL to the same standard, and understand precisely why it is that the two systems were built so differently.
Postgresql with read replicas is ACID-Consistent transactions because single writer, and CAP-AP eventually consistent because distributed reads.
It is easy to agree with you here: "PostgreSQL basically stops working well too, once you start mixing transaction processing and business reporting and BI in the same box at scale." It's worse than that - the app has to be coded before it can be scaled so you get fucked by complexity-scale via ORM a lot sooner than bigdata-scale. But as you sort of say, the point of a data warehouse is to be cap-AP (eventually consistent) through read-replicas without breaking ACID-consistent transactions for the system as a whole.
as to the argument "everything is bad at scale" i think that has merit too, I just gave a talk at ClojureNYC about building real apps with Postgres (tables) vs Neo4J (graph) vs Mongo (documents) vs Datomic (eavt): https://github.com/hyperfiddle/hypercrud.browser/issues/4 (Did I say real "apps"? I meant "balls of mud")
What good is my Postgres single-node ACID if I have to do all this work to deal with replication lag?
Git is another ACID single-writer system with strong consistency and distributed reads.
To be fair, it's an easy win to throw a replica in the mix with no downsides for BI.
Not to mention, BI at scale tends to send data to redshift or the like first
ACID was defined upon Jim Gray's formalization of the terms "transaction", "atomicity", "consistency", and "durability" [1]. It applies regardless of however many nodes a system consists of. It cares about a system holistically, not what it's physically made up of. Gray defined them acknowledging the preexisting work on fault tolerance and high availability with replication and hot standbys, literally situations where it's worth talking about C-as-in-CAP consistency. A transaction is literally defined upon an agreement protocol like two-phase commit. Similarly, Eric Brewer literally defined the C in CAP following the C in ACID [2].
The two concepts are clearly related, if not identical. It's not like I magically can't ever have ACID transactions once a network is involved, as long as the network heals.
To come at this from another angle: ACID transactions are an abstraction. They serve only to make it easier to reason about concurrency and synchronization. If you're telling me that this abstraction falls apart inherently because of the network, then frankly it's not a very good abstraction at all.
PostgreSQL is ACID when it's a system that encompasses a single node. PostgreSQL is not ACID when it's a system that encompasses more than one node. Simple as that.
I think it is even more disingenuous to lull people into a false sense of security just because Postgres is technically "consistent" on a single node. It's 2017 -- your data getting fsync'ed to a single disk, in a single machine on a single rack in a single datacenter in a single region -- is simply not enough anymore.
[1] http://jimgray.azurewebsites.net/papers/thetransactionconcep...
[2] https://pdfs.semanticscholar.org/5015/8bc1a8a67295ab7bce0550...
Postgresql with read replicas is ACID-Consistent transactions because there is a single writer process to prevent data loss. Only the reads are distributed and thus cap-AP eventually consistent.
You are essentially asserting that a precondition for ACID in Postgres is that the underlying storage medium (or at least the bits on them) will never suffer permanent failures, and has infinite 9's of availability everywhere in the world, instantly. Then, and only then, can PostgreSQL provide anything resembling seamless consistency.
Sorry, no dice. This is not how distributed systems work in the world outside the walled gardens. I'm a huge proponent of the cloud, but I'm not a huge proponent of things that only work if you rely on the cloud.
non-ACID writers like Mongo lose writes routinely, every day, often without anybody noticing. There are no guarantees whatsoever about data integrity. ACID writers lose data in 6-sigma catastrophic failures only, and you can control how many sigmas by tuning durability.
You asked a question about HA configurations so I answered in terms of HA configurations. Serving durable HA storage is literally what dynamo/riak is for. "The write operation is durable. dw (durable write quorum) is a configuration setting used to specify how many replicas to commit to durable storage before returning a successful response." https://stackoverflow.com/questions/22736821/riak-database-a...
Anyway I'm interested in continuing to discuss this if you are because this is a subject I am beginning to write about as part of my startup. so this conversation helps me. Perhaps there is a better medium though if you would like to continue?
Pretty sure Postgres has supported two-phase commit since at least version 8.
It's not saying much to say that a database management system is ACID as long as you constrain your updates to a single record in a single table.
What I'm tired of is the rhetoric built upon the dichotomy that Postgres is ACID and MongoDB/NoSQL is not. As it stands, neither is, in any scalable fashion. And in no way is Postgres a panacea for every possible kind of data problem.
And like you said. It's not saying much to say that a database management system is ACID as long as you constrain your updates to a single machine.
There are better things on the horizon, databases that can actually do it all.
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-us...
There is no real good nodejs RDBMS ORM in the class of what other environments provide. I recently had a company rip out nodejs => sequelize => pgsql and replace it with nodejs => protobufs => sqlalchemy => pgsql