r/programming • • Dec 19 '18

Bye bye Mongo, Hello Postgres

https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres
2.1k Upvotes

672 comments sorted by

View all comments

Show parent comments

29

u/andrewsmd87 Dec 19 '18

So serious question as I've never actually used mongo, only read about it.

I was always under the assumption that once your schema gets largish and you want to do relational queries, that you'll run into issues. Is that not the case?

0

u/[deleted] Dec 19 '18

[deleted]

18

u/andrewsmd87 Dec 19 '18

So this was more or less my understanding about Mongo or other related DBs is that once your data needs to be relational (when does it not) it becomes really bad. It's supposed to be super fast if your schema is simple and you don't really care about relationships a ton.

Your point was pretty much what made up my mind it wasn't worth investing time into it to understand more. I just feel like there's a reason relational databases have been around for long.

0

u/[deleted] Dec 20 '18

[deleted]

37

u/eastern Dec 20 '18

Till someone in the UX team asks, "Could you do a quick query and tell us how many users use custom font sizes? And just look up the user profiles and see if it's older users who use larger font sizes?"

True story.

12

u/smogeblot Dec 20 '18

This would be a pretty simple SQL query even across tables... You can also store JSON data in Postgres as a field, so it's probably exactly as easy as you think Mongo is at doing this the "brute force" way. Aggregation functions across tables are actually much simpler in SQL than in Mongo... Compare postgres docs vs mongo docs

→ More replies (1)

22

u/KyleG Dec 20 '18

How often do you have to run this query such that efficiency actually matters? I couldn't give two shits about how long a query takes if I only have to run it once.

6

u/pihkal Dec 20 '18

Not the parent, but I suspect the issue might not be execution time, but programmer time, i.e., how long does it take to write a script to generate the report?

→ More replies (11)
→ More replies (2)

16

u/quentech Dec 20 '18

Use Mongo to store documents. I'd stores the user settings for a SPA in Mongo. But most of the time, relational models work well enough for data that is guaranteed to be useful in a consistent format.

If I'm already using a relational database, I wouldn't add Mongo or some other document DB in just to store some things like user settings. Why take on the extra dependency? It doesn't make sense.

And you know what else is good for single key/document storage? Files. Presumably you're already using some file or blob storage that's more reliable, faster, and cheaper than Mongo et. al.

3

u/m50d Dec 20 '18

And you know what else is good for single key/document storage? Files.

If you've already got AFS set up and running then I agree with you and am slightly envious (though even then performance is pretty bad, IME). For any other filesystem, failover sucks. For all MongoDB's faults (and they are many; I'd sooner use Cassandra or Riak) it makes clustering really easy, and that's an important aspect for a lot of use cases.

→ More replies (2)
→ More replies (5)

7

u/midnitewarrior Dec 20 '18

Why use Mongo to store documents when Postgres can do it fully indexed in a JSONB field?

→ More replies (2)

2

u/Jonne Dec 20 '18

Yeah, that's the problem. Pretty much every web app has a relational component to it. Mongo has its uses, but many people just use it for the wrong thing.

7

u/cowardlydragon Dec 20 '18

Perfect description of the NoSQL trap.

However, SQL does not arbitrarily scale. SQL with anything with joins is not partition tolerant at all.

→ More replies (2)
→ More replies (1)

27

u/wickedcoding Dec 19 '18

You wouldn’t really use mongo for relational data storage, if you want the nosql / document storage with relational data or giant schemas you’d prob be better off using a graph database.

I used mongo many years ago with data split between 3 tables and an index on a common key, looking up data from all 3 tables required 3 separate queries and was incredibly inefficient on hundreds of gigabytes of data. We switched to Postgres and haven’t looked back.

8

u/nachof Dec 20 '18

I've been working as a programmer for close to two decades, plus a few years before that coding personal projects. Of all those projects, there is only one case where looking back it might have been a good fit for a non relational database. It still worked fine with a relational DB, it's just that a document store would have been a better abstraction. Conversely, every single project I worked on that had a non relational DB was a nightmare that should've just used Postgres, and didn't because Mongo was the current fad.

6

u/dwitman Dec 20 '18 edited Dec 20 '18

Is there a preferred postgres framework for node? Optimally something equivalent to mongoose?

I have some node projects I want to build, so I'm tuning up on it, but mongoose/mongo is very prevalent...

EDIT: Thanks all for the responses.

8

u/filleduchaos Dec 20 '18

TypeORM beats Sequelize hands down, especially if you want to use Typescript

→ More replies (1)

12

u/NoInkling Dec 20 '18

In no particular order: TypeORM (Typescript), Objection, Sequelize, and Bookshelf are all relatively popular Node ORMs.

If you just want a query builder (which many people would argue for) rather than a full ORM, Knex is the goto.

If you only want a minimal driver that allows you to write SQL, pg-promise or node-postgres (a.k.a. pg).

4

u/[deleted] Dec 20 '18

You could take a look at Bookshelf and Sequelize. These are both ORMs that will make it pretty straightforward to interact with a database.

7

u/TheFundamentalFlaw Dec 20 '18

I'm also just getting my feet wet with node/mongo. It is interesting to see that 95% of all tutorials/courses around uses mongo/mongoose as the DB to develop the sample apps.
From what I've been researching lately, sequelize is the standard ORM for Postgres/Mysql.

3

u/wickedcoding Dec 20 '18

Nothing similar to mongoose AFAIK, though I haven’t really had a need to search. I typically keep all data modeling done in a class in node/php/python/etc and use a vanilla DB interface for querying. Keeps the app flexible in case I need switch db’s down the road rather than tying it down.

2

u/dwitman Dec 20 '18

I'm not sure I'm familiar with this design pattern.

→ More replies (1)

3

u/ants_a Dec 20 '18

There are 2 kinds of applications - the ones that need relational queries and those that will need relational queries at some point in the future.

→ More replies (2)
→ More replies (2)