Comparison of Joins: MongoDB vs. PostgreSQL

https://www.enterprisedb.com/blog/compare-mongodb-vs-postgresql-join-command

by ahachete • 6 years ago

62 68 6 years ago

enterprisedb.com

tasubotadas• 6 years ago

If you picked mongodb and you are using joins, you've picked a wrong tool for a job.

Beefin6• 6 years ago

right, this is an apples to oranges comparison.

you're comparing the feature that RDBs do best to the feature that NoSQL DBs do worst...

ldng• 6 years ago

Like NoSQL proponent, never do that. Worst offender often beeing Mongo (although they calmed down a bit since "Web-scale" days ...)

AmericanChopper2• 6 years ago

The most common use case for Mongo is storing relational data for web apps, and the most common outcome for those apps is complete dysfunction. How do I know that’s the most common use case? Aside from my own anecdotal experience, you just need look at the features those DBs implement. They’re constantly implementing new RDBMS-like and ACID-like features. They wouldn’t be doing that if that wasn’t their market. Why does this happen? Because people who don’t know better keep thinking that they can somehow work around the constraints, and just make a mongo (or dynamo) RDBMS work somehow. It is an apples to oranges comparison. But it’s worth making, because of the large number of people who think it’s ok to substitute oranges into apple pie recipes.

commandlinefan• 6 years ago

And the corollary: if you store data, you need to use joins.

throwanem2• 6 years ago

Embrace denormalization! It makes for splendid job security.

Beefin6• 6 years ago

this isn't always true there are plenty of schema designs for storing data based on your application's usage patterns.

oftenwrong• 6 years ago

Not if you're just doing vanilla document storage.

baq2• 6 years ago

'professional managers' might not know this.

daneel_w• 6 years ago

This was quite the lopsided comparison - a document store just doesn't get fair competition in a relational setting. Additionally, both the SQL and the MongoDB queries appear unnecessarily complicated (or inefficient) for the examples they illustrate.

throwanem2• 6 years ago

This does feel like an article that would have made more sense in 2013 or so, back when the habit of mistaking a document store for a database was much more widespread.

d_watt2• 6 years ago

Is this actually an objective truth? "relational" just refers to the relation within the table, it's less about having a database system with good inter-table relationship handling. It happens to be that a lot of the things we think about as relational are OLTP and have good fkeys, etc.

Is there any real reason why a document store can't have good joins between collections? If you index the lookup keys, I don't understand what about the underlying document model would make joining impossible to optimize as well as a relational model.

alexpetralia2• 6 years ago

I don't think most document stores enforce foreign key relationships (and hence consistency) like RDBMS do, so in practice that would make joins difficult.

ahachete6• 6 years ago

Here is the code for the queries: https://gitlab.com/ahachete/pgmongojoins/-/tree/master/post-... Feel free to send a MR improving it.

stepbeek2• 6 years ago

While I think it's easy to poke fun at this article - relational database better at handling relational data, more at 10 - it does make me want to understand why one would choose mongo over postgres?

baq2• 6 years ago

when you need a geo-replicated and highly available data store in a way that doesn't make you lose sleep. (also, if you don't need to join relations in it. or have relations at all.)

dsun176• 6 years ago

Replication and scalability I think

Beefin6• 6 years ago

When you don't want to use an ORM, want to scale horizontally, want to use BSON data types and all the indexing capabilities around them, etc.

jeltz• 6 years ago

PostgreSQL has the JSONB data type which is essentially the same as the BSON type except slightly better optimized for reading partial documents. And PostgreSQL also provides good indexing support for them, and did so before MongoDB.

mixermachine4• 6 years ago

- Faster development speed - Unknown content of the object that should be stored (and run indexes on this content)

nicoburns2• 6 years ago

You can do that by using a JSONB column in postgres (including indexes), and that way you can upgrade to typed columns at yout leisure (and on a per-column basis).

Personally, having inherited a database that wqs absolutely chock full of bad data due to the lack of schema, I'd be very reluctant to go that route unless I really needed to.

fatbird• 6 years ago

There's really only one reason to choose mongo over a competent RDBMS, and that's schemalessness at the database level--which most users of mongo then toss away by adding a schema package at the code layer.

If your data is relatively freeform with good indices on stable fields, mongo is hugely convenient, and can be easily structured to scale horizontally. For non-join based aggregation (i.e, aggregation within a collection), mongo is very performant, and works fine for a lot of use cases. I'm using it storing large amounts of simple timeseries data and it's great, largely because my use case doesn't require more complex data structures.

As soon as you want to deal with more complex structured data, mongo is worse than any RDBMS. The only viable noSQL solution to complex structures is denormalization, which is sometimes a legit choice. But unless you know your primary use is just retrieving a set of documents based on indexed fields (and many are), get an RDBMS.

pritambarhate2• 6 years ago

MongoDB has built-in auto-failover with replica sets. It is possible to set this up for PGSQL with third-party tools but it's hard to get right.

MongoDB has built-in multi-instance sharding support. Again this is possible for PostgreSQL with table partitioning and FDW but it is hard to maintain.

zozbot2343• 6 years ago

MongoDB has built-in auto-failover with replica sets. It is possible to set this up for PGSQL with third-party tools but it's hard to get right.

PostgreSQL documentation makes it quite clear how to set up HA, I don't think you need any third-party tools other than general OS-level support for failover.

https://www.postgresql.org/docs/current/high-availability.ht...

jmull4• 6 years ago

I can’t address MongoDB, but nosql vs relational generally, there are two reasons:

(1) what’s faster than a fast join? No join. With nosql you have more flexibility to store the data organized in the same way it is accessed. You don’t need to join to another table if the data your app needs is already directly part of the main data the app requests. You do need to understand your access patterns well, and develop migration plans when they change.

(2) scalability. nosql databases generally let you scale horizontally more easily/gracefully than relational databases, though there are trade offs.

Put it together and you get performance at scale, though you generally need to understand your data access patterns and usually need to be more resilient to inconsistencies.

zozbot2343• 6 years ago

what’s faster than a fast join? No join. With nosql you have more flexibility to store the data organized in the same way it is accessed.

You can definitely do this in PostgreSQL via materialized views. They're directly supported in recent releases, and they don't require you to denormalize the underlying datamodel unlike NoSQL.

ahachete6• 6 years ago

You do need to understand your access patterns well, and develop migration plans when they change.

This sounds like a minor issue, but it's a huge operational pain. Migrating a data structure to accommodate new queries involves operations and application changes, both substantial. Migrating all data in a consistent way is either extremely hard or requires significant downtime.

In my opinion, for most cases, this problem is significantly worse than doing joins in first place.

thinkx2• 6 years ago

though there are trade offs.

Please elaborate on this, it would be instructive

stepbeek2• 6 years ago

You do need to understand your access patterns well,

I've found that being able to change quickly is more valuable that the marginal performance boost that mongo would give. Denormalization is possible in postgres.

Where have you seen this trade off go well?

psychometry• 6 years ago

We're still talking about MongoDB? Why?

strbean• 6 years ago

MongoDB is web scale. [1]

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

_t0du• 6 years ago

Because lots of people are still using it. In Q1 2020 they 89m in revenue, up from 50m in Q1 2019. Just because something is bad technically doesn't mean people will immediately abandon it. See: php.

liquidify• 6 years ago

Ok everyone, calm down. I think it is obvious that the author knows that he is comparing apples to oranges here... but that isn't the point. The point of this article was to quantify the difference. His work accomplishes that for these specific tests very well. Yes, we know relational systems are better in these cases, but it is useful for those considering no-sql solutions to see this kind of hard data.

diddid• 6 years ago

This should really be titled “A comparison of aggregates”.

throw_m239339• 6 years ago

Can someone who is using MongoDB and a RDBMS at the same time tell me the exact use cases where MongoDB is fitter? Structured logs? Caching? Sessions? And why MongoDB does it better?

mixermachine4• 6 years ago

Relational DBs for everything that needs joins. MongoDB is horrible with that and should not be used. One would not put an off-road vehicle on a race track and expect it to win.

I use MongoDB for everything where I don't know the data structure before hand. MongoDB is very good in indexing unknown data structures and makes them searchable. Also, when I build prototypes I often use MongoDB.

anthony_doan• 6 years ago

Cluster is very easy in MongoDB and for unstructured data. I've looked into clustering postgresql a few time and it seems like a pain in the butt. TBH, storing data without thinking about relation is just kicking the can down the road.

My previous company store coupon code on it (referrals). I prefer a hash nosql for that though (cassandra) but for a one man shop it's overkill.

---

edit:

IIRC postgresql have their own document storage like MongoDB. I just never had to use such thing because I guess I'm too OCD about how my data suppose to look like.

airocker• 6 years ago

The biggest one is searching jsons. You essentially have a database that stores jsons and you can search it. Just dump a json and search it goes a long way. My problems are more the atomicity guarantees which are not very consistent.

ahachete6• 6 years ago

Co-author here. Thank you all for your comments.

While I understand is tempting to easily conclude that this is apples-to-oranges or that "obviously a relational database is better at data relationships", I recommend to dive deeper into the topic.

First of all, almost all data models you may think of are in some or another way relational (call it "related data", if you prefer). So any database, RDBMS or NoSQL or whatever, will need to deal with data that is related to other bits of data. So this is, from this perspective, very apples-to-apples IMHO.

Second, and regardless of the above statement, the exercise here is to model a data model that is, necessarily, two (or three) pieces of related data. And actually we considered the two models that MongoDB themselves consider for data modelling: embedded and reference. This is explained in the post and references to official MongoDB documentation are provided.

Third: benchmark is open and public. The repository also contains all the query examples used in the post. If anyone considers that there's a better way to represent this data model (problem statement), that would still answer all the "business" questions (queries) considered in the post, please send a Merge Request to the repository. We will be very happy to analyze it.

All in all, this is an exercise of data modeling, for a given dataset. MongoDB requires data modeling, is not "schema-less", and this is pervasive through their official documentation. The reference model, and their $lookup operator, are not a corner case nor a hidden downplayed option. It is a first-class operation, well advertised. But its complexity, performance and rewriting needs to adapt to changes are what are not, apparently, advertised, after our observations.

verst• 6 years ago

I would really love to see a direct comparison for scaling MongoDB and PostgreSQL.

When do I usually need to scale up / out in either database? How do I assess that? And how do I actually go about scaling?

Specifically I would love to know how to scale up and scale out (what are the different multi-node options and what are the consistency / replication delay guarantees)?

The last time I used Mongo in production (2013) most startups eventually had to switch databases or hire a consultant to scale. This has always stuck with me.

gshulegaard• 6 years ago

I have spent most of my (limited) career scaling PostgreSQL with (IMO) surprisingly good results.

Most recently I have been using Citus and it has been ridiculously easy to shard data.

To be fair I have only been exposed to workloads of a few Terabytes of data ingest a day so YMMV.

Unfortunately, I can't compare to Mongo as I have had somewhat limited experience with it.

matchy• 6 years ago

can’t compare to Mongo as I have had somewhat limited experience with it

Doesn’t seem to stop most people here.

BenoitP• 6 years ago

A basis for the apples to oranges argument is that you don't use MongoDB when you need JOINs.

To me, this almost never happens. You almost always need JOINs, otherwise your data is sterile and useless. What point is there to talk about entities devoid of relationships to other entities? Data is always relational; we don't live in a 1-dimensional world.

The only way I see it being useful is for scaling purposes. But there are way better, more stable, more resistant to failure kv stores out there.

kthejoker2• 6 years ago

Only one person in this comment thread mentioned CAP theorem, which is the (highly informal*) rationale for NoSql's existence and also its deliberate aversion to join dependencies (which more or less violate the core principles of eventual consistency modeled distributed data stores.)

Useful links for erudition:

https://arxiv.org/pdf/1302.0309.pdf

https://codahale.com/you-cant-sacrifice-partition-tolerance/

https://martin.kleppmann.com/2015/05/11/please-stop-calling-...

https://www.somethingsimilar.com/2013/01/14/notes-on-distrib...

https://www.microsoft.com/en-us/research/publication/replica...

Comparison of Joins: MongoDB vs. PostgreSQL

Related Stories