I was there in 2010s migrating Mongo databases chosen by "expert consultants" to Postgres and dealing with the fallout of massive tech debt those decisions usually caused. Won't get fooled again - no matter how many fluff articles they write you will sooner find me rotting in this barren earth than see me pick MongoDB for a new project.
Are any of you guys old enough to remember when Marc Fleury got caught in an astroturfing scheme involving JBoss employees? That’s actually how I learned that word had been coined.
The MongoDB Team didn’t do exactly the same, or at least nobody caught them, but they did have a massive hype cycle, selling snake oil full of serious concurrency bugs. Managed to time their funding right so they ended up with enough money to buy a completely different NoSQL implementation, that actually did work (mostly), discontinued work on their code and relabeled the other implementation as Mongo.
I don’t patronize companies built on a bed of lies. Because how do you trust the lies stopped? They have a proven track record of being good at it. And you’re rewarding all of that behavior. The ends justify the means? Fuck that.
I suspect a good amount of the hype around NoSQL was driven by frontend developers transitioning into backend work via Node, and Mongo being relatively simple to get started on compared to relational databases. And that culture seems to have stuck. To this day, many popular backend js frameworks either completely ignore relational data storage or slap some bare bones interface over it.
I believe that this is also why we're starting to see a surge in people wanting to run SQLite as their backend database. It's similarly simple to start out with, and also similarly flimsy when dealing with actual data integrity. Very limited types, limited isolation options, ref integrity disabled by default (Mongo DB also disables things by default that hurts their benchmarks).
But hey, SQLite is better than Mongo DB, at least. So we're making progress
Good point! SQLite is simple and great for small projects, but its limits with data integrity and concurrency show at scale. Still, it's a more predictable choice than MongoDB, which has its own quirks. Definitely progress!
There might be some truth in that. I've come to respect SQLite more as a serious database though. It can perform well if you can manage the trade-offs of running on a single server and turn the right knobs. The upgrade path to Postgres is also a lot clearer than with Mongo.
Not OP, I'm sure it was Mongo to PG. I've seen it too.
Once someone couldn't scale (c2012) their MySQL. I recommend analyzing and working on the code. A competing consultant said Mongo. So, three years later they called me back to un-fuck that thing (that was only 3/4 done anyway) and then move everything to PG (and a fixed schema and some improved caching).
I had such a bad experience with Mongo DB back in 2012-2013 that I don't think I'll ever use it again, or even really consider it. But maybe it's changed and gotten better since then?
Also, Postgres. It has built in support for json data types, can index on json fields, and do most of the stuff you'd want to do in mongo while not locking you into that paradigm for the parts of your app that don't need it.
With regard to ArangoDB, the Community Edition is for personal or internal business projects (non-prod, up to 100GB). There is also a managed version and self-manage Enterprise version that companies use with their apps.
It's ugly but having a field that's just a dictionary is really handy and not too ugly.
We use a lot of them for things like "tags" (which can take freeform user- or ml- supplied image tags in key:value format). I adore it. (We tried mongo with one of our annotation systems and regretted it.) It's a very nice way to balance quick development (you don't need a schema change to try a feature for a while) with the benefits of a mostly schema-defined db.
Using a gambling company as an example for a win in the IT space sounds to me as if UPS was bragging about winning a contract with a drug cartel to import fentanyl and crystal meth.
Weird choice. Doesn't give you much faith they have a lot of examples of companies migrating from Postgres.
MongoDB gets a lot of hate and created a bad reputation for itself by way of a very successful marketing campaign where they convinced a whole lot of companies to replace whatever RDS they were using with MongoDB some years ago. This caused a lot of RDS-driven applications to uh, experience a lot of development issues.
It basically never makes sense to drive an application with MongoDB, which is why a lot of folks think it's strictly worse.
A perfect MongoDB (or any document db, really) use case has zero relationships. This is accomplished by duplicating data across documents where you would normally use a foreign key in an RDS. Naturally, this is anti-pattern for RDS-minded folks and everything you'd want to do with Mongo stems from this mode of thought (preprocessing/data replication instead of lookups).
Personally, I've had great success with Mongo and appreciate it for it's incredible depth in text searching via Atlas Search. Surprisingly, the web interface for Atlas in general is actually quite good and it's the only one I can bear to use; I usually can't stand them.
I have deployed Postgres and MongoDB at petabyte scale. I am happy to answer questions from others who are intellectually curious about differences between the two that would matter to users who have to spend serious amounts of money on their databases.
No, it's frankly not possible to deploy Postgres at scale without a third party (or hand-rolled) HA/scaling solution. I worked on an application that hand-rolled one after considering several products.
The quotes from the CEO are misleading, implying MongoDB is document-based and PostgreSQL is 100% relational. This is not true, PostgreSQL has had JSON support for quite some time.
Document-oriented databases are a subclass of the key-value store.
Postgres jason types are blobs in an RDBMS, and jsonb is to be avoided in almost all cases.
I am not a MongoDB cheerleader and I am a huge fan of Postgres when SQL is appropriate, but equating an ACID style DB with a key value store misses the point.
But it is horses for courses, people using MongoDB for acid transactions when support landed in v4 is where most of the problems came from.
When deployed in their core domains, both work better than the hacks implemented to artificially make them competitors.
> Postgres jason types are blobs in an RDBMS, and jsonb is to be avoided in almost all cases.
You might be uniformed (or misinformed) on this topic. JSONB is not just a "blob" in Postgres. It's a first-class value type with full query-ability and indexing support.
> JSON data is subject to the same concurrency-control considerations as any other data type when stored in a table. Although storing large documents is practicable, keep in mind that any update acquires a row-level lock on the whole row.
Concurrency is far more nuanced in MongoDB and storage of documents has far fewer side effects than jsonb.
The ad hominem is ironic with someone claiming RDBMS and key value stores are equivalent.
Document updates are atomic, with replica sets. Reads will be eventually consistent.
Professionals consider weigh the tradeoffs consistency vs partion tolerance, availability, synchronous vs asynchronous communication implications etc...
Nothing here is a silver bullet, it is about choosing the least worst option for a data domain.
We are in the cloud era, which is by its nature distributed.
The era of vertically scaled monoliths is mostly over for most people.
The book 'Software Architecture: The Hard Parts' is probably a path forward for you, but any books on modern data architecture would be.
Hint: even your ATM card doesn't use ACID, and many needs can improve performance, availability and resilience by not paying the cost of ACID transactions.
It is a far more complex subject than your posts suggest.
> The book 'Software Architecture: The Hard Parts' is probably a path forward for you, but any books on modern data architecture would be.
I'll send you some books to read, too.
> Hint: even your ATM card doesn't use ACID
I guarantee you that the actual database handling those ATM transactions is ACID-compliant. The banking institution itself couldn't even be certified by the FDIC or the Comptroller of the Currency (OCC) if their database system wasn't, at the very least, ACID compliant.
Out-of-band transaction resolution is a completely separate topic and has nothing to do with databases, or ACID, or anything else.
A key/value store is easy to build in Postgres, just define a table with a key column and a value column, that's it. Given that both key and value can be of datatype JsonB or BLOB, there's no restriction in generality, just, you know, aptness for the purpose. Now if you do that, you can—in Postgres—define additional structure or choose a different model entirely if your KV store turns out to be less ideal for whatever you want to do. MongoDB does not give you that choice.
For people who don't want to take form participants in this thread, maybe you should consider listening to no other than Mike Stonebraker[1]:
NoSQL databases that store data as JSON documents, such as MongoDB and Couchbase, benefited from developer excitement over a denormalized data structures, a lower-level API, and horizontal scalability at the cost of ACID transactions. However, document stores “are on a collision course with RDBMSs,” the authors write, as they have adopted SQL and relational databases have added horizontal scalability and JSON support.
“Another wave of developers will claim that SQL and the RM are insufficient for emerging application domains,” they write. “People will then propose new query languages and data models to overcome these problems. There is tremendous value in exploring new ideas and concepts for DBMSs (it is where we get new features for SQL). The database research community and marketplace are more robust because of it. However, we do not expect these new data models to supplant the RM.”
The main trouble I have with mongo or document databases in general is that using them effectively requires a lot of design thinking up front. You need to really understand your domain model, in a DDD sense. This isn't usually made clear to people.
Document databases are good for working with / storing aggregate root objects and related entities. If you don't know what that means, or are feeling your way through a new domain and aren't in a position to decide if you're really dealing with an aggregate root object or not, or think things might be subject to change later, put the tools down and go with something more conventional.
Additionally, if you do use mongo for your operational data store, you should probably consider combining it with read-projections in a relational style DB too, or at least more conventionally defined flattened collections in mongo, in order to service bulk read style queries. Aggregation queries in mongo can get out of control quickly if you're not careful. Much better to plan for that early. And if you end up separating concerns like that, you'll probably find yourself wondering why you didn't just go with Postgres from the start.
In the 2010s when the MongoDB craze was in full swing I took several deeper looks at MongoDB but all that I was left with was befuddlement—why? why would I choose Mongo over a real database? It never made any sense.
Mongo is hated here but I’ve made many services with Postgres and mongo is just far easier to use. Json tooling in Postgres is not as good.
I don’t particularly hate or like any one database, but thinking about migrating the workloads that I have in mongo to Postgres just gives me no interest. Mongo solves the problems I have very well.
That's the thing about Mongo, it's great until it's not. And Not comes quickly for many projects.
There's probably tons of small Mongo installations all over the internet doing great in their little niche. But the moment a project gets too big for Mongo, it becomes a problem very quickly. I suppose it's like comparing a bike to a car. If your problem is getting around a small town with nice weather, the bike wins. But the moment you need to move 5 people on the interstate to the next town in bad weather, there's no real choice besides the car.
Granted I really don't spend my time evaluating databases rigorously, but I find claims that MongoDB is more performant than Postgres really difficult to believe. It sounds like a skill issue to me. MongoDB is technical debt, it has it's place for when you don't know what you're doing and you just need to throw your data somewhere. Eventually you're going to grow to a point where the overhead of not using real data structures is going to cease to be worth it. (I realize this is directly contrary to what's stated in the article, but who are you gonna believe, MongoDB or a random HN commenter? :)
