MongoDB takes a swing at PostgreSQL after claiming wins against rival | Hacker News Reader

MongoDB takes a swing at PostgreSQL after claiming wins against rival

theregister.com

24 pointsBender54 comments

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.

Just checking you said migrating mongo to postgres. Did you mean the other way around? I still don't understand how mongo is still in business.

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

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.

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!

He said migrating mongo to postgres because someone else make the stupid decision of using 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 guess you'll miss out on the enjoyable syntax then.

Generally speaking I agree, having structured typed data is going to make for an easier platform to work with.

But are you saying Mongo specifically is the problem, or are you saying any non relational data store is the issue?

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?

Anyway. I just use Postgres.

> Anyway. I just use Postgres.

Same. Because I care about my data.

If you like the document db idea there are a lot of choices, especially

https://arangodb.com/

which I think gets little attention because people who use it see it as a secret weapon. Too bad about the license though. Also

https://couchdb.apache.org/

and

https://developer.marklogic.com/

Isn't PostgreSQL supporting JSON and queries over them? [1]

[1] https://www.reddit.com/r/django/comments/14f68rz/postgresql_...

It does. See https://www.postgresql.org/docs/current/datatype-json.html

I think it is ugly as hell to work w/ json documents in pgsql but most of the eng managers I’ve known think you couldn’t get fired for choosing pgsql.

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.

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.

Arango isn't comparable, the Free edition is extremely limited. PostreSQL doesn't say how much you are allowed to store or what you can use it for.

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.

Comparison - https://arangodb.com/subscriptions/

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 loathe so much getting data out of mongo in a reasonable fashion. Pipelines are a nightmare to accomplish what you can do in 10 seconds writing sql.

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.

vanilla, single-node postgres ?

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.

json/jsonb, hstore, ltree, btree/gin/gist, enum types, nested record types... the list goes on and on. PG is _very_ hard to beat.

Mongodb certainly isn't doing it.

Their entire value proposition boils down to

    create table docs (
      doc jsonb
    );

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.

[0] https://www.postgresql.org/docs/current/functions-json.html

Fighting with autocorrect, 'json' type is a blob with a path search in front.

https://www.postgresql.org/docs/current/datatype-json.html

> 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.

> Concurrency is far more nuanced in MongoDB and storage of documents has far fewer side effects than jsonb.

Is the concurrency "nuance" that Mongo DB allows 2 updates to a JSON doc to race with each other?

> keep in mind that any update acquires a row-level lock on the whole row.

Yes! Thank you Postgres developers. This is what _professionals_ do.

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.

You're kinda out of your depth here...

"jsonb is to be avoided in almost all cases"

Why's that?

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.

Postgres is 100% relational AND supports JSON.

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.”

[1] https://www.datanami.com/2024/07/08/dont-believe-the-big-dat... discussion: https://news.ycombinator.com/item?id=41406420

Redis is fast too, but I don't go around comparing it to a proper database =/

/dev/null scales better than all of them

But is it web-scale?

"Mongo DB Is Web Scale" is pretty entertaining: https://www.youtube.com/watch?v=b2F-DItXtZs

(https://news.ycombinator.com/item?id=1636198 linked to the original platform, which sadly shut down after a few years.)

/dev/null : the optimal solution for write-only workloads

It's eventually consistent as well, so same guarantees as MongoDB in that regard.

And it massively improves backup times (let alone, restores)

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.

All I know is, I’m using PostgreSQL and enjoying it!

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.

I heard MongoDB is webscale, yeah?

https://www.youtube.com/watch?v=b2F-DItXtZs

I consider MongoDB a huge warning sign; if you think that's a good idea I don't want anything to do with your code.

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.

That's been my experience with mongo every time

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? :)

Reply on news.ycombinator.com