Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye MongoDB, Hello PostgreSQL (2015)

developer.olery.com

Post reply on HN
Print view View original

81–90 of 172 posts

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#81

Post by Jean-Philipe »

technosamay20 wrote: post #55

There were many questions asking about recent experience with MongoDB. I have some recent experience so wanted to share with everyone. My background: 2007-2010: Used MySQL to run a social network for 50M+ users. Would send 2B messages on peak days. All powered by Mysql. 2015-2020: Used Mongo to power a top 5k site. Zero downtime and dataloss in 5 years. Used Postgres for internal non user facing database So I have fa…

> With mongo, you just add a column and you are done.

No, usually you are not done. Your data doesn't have the column. So either you write your code in a way that it can handle the column being optional or you write code to read each document and add the column manually.

I've started out with mongodb on Fit Analytics originally, until we noticed at some point that our data was an inconsistent mess and we'd implement constraints in our back-end code to make sure the data is consistent. Eventually it became just easier to have an SQL database taking care of all those constraints, and we luckily migrated away.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#82

Post by arcturus17 »

deepGem wrote: post #62
javchz wrote: post #29

I use MongoDB as a front-end that does full-stack prototypes from time to time in Node, and it's great using javascript from start to finish, you don't have to switch mental gears, so creating an MVP it's fast... but. Sometimes I feel like I'm just avoiding SQL for no reason, not using any of the advantages of NoSQL, and only using Mongo as a SQL-wannabe with a shoehorn like mongoose. I wonder how many MongoDB projec…

When you are creating MVPs time matters the most. You are anyway going to throw it away and build something better. I was using Mongo and NodeJS a lot but then switched to Python. Now I find the world of ORMs to be onerous. I just want to define tables in MySQL and just run raw SQLs. The best compromise I have found so far. I mean it does involve boiler plate code but ultimately it's an MVP. And you are right, most o…

I also moved away from NoSQL for prototyping; as I recount in the sibling comment, I think the touted increase in dev speed is a myth, as the only penalties in dev speed for SQL come from (a) learning the tech and (b) thinking of your data model ahead of time, both fixed costs which dilute over time and eventually make you faster.

> Now I find the world of ORMs to be onerous

Funnily enough, I've also moved to Python, Django in particular. However, I'm having no problem whatsoever with the Django ORM and it's serving me extremely well for prototyping - I feel it is very easy to operate and that I can move at the same speed that I ever could with NoSQL after just a couple of months of practice.

Have you tried the Django ORM in particular? And what about the ORMs you've tried makes them onerous?

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#84

Post by pietrovismara »

ekvilibrist wrote: post #15
anonytrary wrote: post #2

I learned a framework several years ago and its default db was MongoDB. So I worked with MongoDB for a few years. Then at my job I used PostgreSQL for a several months. I will probably never use MongoDB again.

I'm sorry you had to go through that.

Oh please, quit the bullshit elitism.

I think postgres is a way more robust solution than mongo, but I've had my worst db experiences having to deal with a postgres db with almost all the business logic in triggers. That was a huge pain in the ass to maintain and understand.

Mongo is defnitely a limited solution, but for certain cases it just works pretty well, with less complexity than postgres. At one of my jobs, I've setupped and maintained a Mongo cluster that did its job without causing any fuss for years.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#85

Post by synthmeat »

jackdh wrote: post #70
technosamay20 wrote: post #55

There were many questions asking about recent experience with MongoDB. I have some recent experience so wanted to share with everyone. My background: 2007-2010: Used MySQL to run a social network for 50M+ users. Would send 2B messages on peak days. All powered by Mysql. 2015-2020: Used Mongo to power a top 5k site. Zero downtime and dataloss in 5 years. Used Postgres for internal non user facing database So I have fa…

>You can change you server type or mongo version with zero downtime. How so? All the documentation on upgrading say you need to shutdown each instance to then step up to the next minor level. For instance 3.4 -> 3.6 -> 4.0 etc. https://docs.mongodb.com/manual/release-notes/4.0-upgrade-st...

If you're using replica set, as you should for anything other than development (and even in development, sometimes you need a replica set for some features), you just sequentially upgrade each one. It goes down, clients figure out the new topology and continue working.

I'm also running on MongoDB, top 6k site and while I wouldn't say there weren't any issues, uptime is wonderful, I sleep well, and have zero problems with modeling the domain as a document collections instead of relational. Can easily imagine that it would not be great fit for many other use cases. Not using Atlas as GP, so it's more work, but I'm trying to be scrappy.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#86

Post by Ceezy »

bildung wrote: post #17
menzoic wrote: post #11

Earlier quoted context omitted.

What if you didn't need relational queries and was dealing with a large volume of data that needed to be sharded?

In what scenarios does one work on data without any relations? Honest question - perhaps I'm too used to think in SQL but even with e.g. a completely flat bunch of documents one usually needs at least access control (i.e. document owners, which is a relation).

Redis is schemaless and make perfect sense that s an high availability storage in memory storage. And most (web) projects use something like Redis.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#88

Post by justsomeuser »

rwoerz wrote: post #54
anticristi wrote: post #25

Earlier quoted context omitted.

To me, "warm" (not hot) data falls into one of two boxes: - schema on write: You know what future queries you will ask. Use SQL. - schema on read: You don't know what future queries you will ask. Use object storage. Of course, in practice, part of your data will be schema on write and part on read.

Maybe I do not get your point but I have a complete opposite opinion. If you do not know about your clients' queries, you are better off with SQL since it enables clients to query exactly the data they need. If you know about future queries, you can shape your object or document storage or db beforehand to match these queries.

I agree with you. SQL allows for a much larger set of possible unknown-at-design-time queries as the data is broken down into atomic units.

With a document store, you often find yourself de-normalising and copying data to new collections on-write to deal with the limited query language.

This means your writers often implicitly encode the possible queries.

As an example, in Redis if you need a 3 way join/filter, you will either a) have your application read all the data and filter it or b) maintain the filtered collection via writers copying the data.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#89

Post by solidasparagus »

remus wrote: post #58
solidasparagus wrote: post #51

Earlier quoted context omitted.

I'm less sure about this. One advantage of NoSQL is that the serverless offerings blow away any SQL DB-as-a-service offering that I've seen. I think that's because NoSQL databases give you minimal, but easy-to-reason-about scaling properties whereas SQL databases do more for you, but at the cost of greatly increased complexity. I think pretty highly of AWS Aurora Serverless and the UX is still garbage in comparison t…

Frankly it sounds like you just don't need a relational database. Their whole selling point is the strong guarantees they provide about your data, and if you aren't using those then you're basically just writing files to disk in a very convoluted way.

You're absolutely right, I don't need a relational database. There are many use cases that don't need relations and avoiding the complexity introduced by RDBMS features I don't need is where NoSQL shines.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#90

Post by chris_wot »

menzoic wrote: post #75
chris_wot wrote: post #13

Earlier quoted context omitted.

The article doesn't give any insight into the cause of the performance issue because they coudn't work out what that cause was: In another instance we noticed degraded performance of our applications and managed to trace it to our MongoDB cluster. However, upon further inspection we were unable to find the actual cause of the problem. No matter what metrics we installed, tools we used or commands we ran we couldn’t f…

True, but it seems like they blamed it on MongoDB just being bad without justification and proposed Postgres as the solution.

No, it seems like the diagnostics tools they were provided didn't help them get to the bottom of the very bad performance issue they were actually having with MongoDB, and then they proposed Postgres as the solution. As most companies do, eventually.
Post reply on HN