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

131–140 of 172 posts

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#131

Post by samlambert »

bushbaba wrote: post #124
samlambert wrote: post #121

Earlier quoted context omitted.

Well it depends what you consider scale. When you look at the high scale deployments like Slack, YouTube, GitHub, Square, etc they are all using Vitess and MySQL.

YouTube doesn’t use just mysql or vitess these days they migrated to other google databases. Slack, GitHub both are stupidly shardable. I doubt it’s one RDBMS handling every customer, chat room, git repo. And instead they’ve segmented the workload across multiple instances. That doesn’t work for every use case

Of course they run on multiple instances. It doesn't work for every use case but it works for more than people realize. Too many people vertically scale, or add read replicas which is a ticking time bomb.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#132

Post by nathanwallace »

colesantiago wrote: post #118
nathanwallace wrote: post #116

Earlier quoted context omitted.

Postgres is incredibly flexible and scales beyond what most projects will ever need. We use it both as a very large scale CMDB store for https://turbot.com and as an small embedded DB for https://steampipe.io . Use cases where we hit road bumps earlier were: 1. High churn data. Postgres copies data for each rite update and then vacuums to clean the old versions. These use cases dominated our DB load and moving them o…

Even in cases for regional replication? Because this is the use case I am looking for, something like Spanner but cheaper.

Cross-region replication of data is always significantly harder, definitely consider if cross-AZ would be sufficient for your case (which it often is). Postgres can definitely be configured for a cross-region scenario, but the approach varies a lot depending on your recovery needs.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#133

Post by dheera »

kornish wrote: post #67
dheera wrote: post #46

Earlier quoted context omitted.

> Eg. Dump all of the data to S3 and search it in parallel via AWS Athena. Too proprietary. Can't be run locally, on robots, etc. Can't be transferred to other cloud providers. Also S3 is horribly slow to write or delete thousands of records at once.

> Too proprietary. Every major cloud provider has a blob store. Most are S3-interface compatible, or can be fronted by something which is, like Minio. > Can't be run locally, on robots, etc. If the contents of your S3 keys are just line-delineated JSON files, you can easily download those files and run scripts or process them locally. > Can't be transferred to other cloud providers. Again, not true — a tool like rclo…

> On the other hand, if you batch records into files of appropriate sizes

Too much work. If you're a startup that's too much stuff to maintain. Much easier to get a hosted MongoDB and launch tomorrow.

And when you only have 2 months rent in the bank and investors want demo after demo in order to give you cash, tools like MongoDB do make a difference. And yes, I've been in that situation before.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#134

Post by sam_goody »

menzoic wrote: post #7

MongoDB and Postgres have very different strengths and weaknesses. It sounds like they didn't consider the needs of their read and write patterns before they decided to go with MongoDB and then blamed it for not being a good fit for their use case. The article doesn't give any insight at all into the cause of the performance issues, just that they happened. It could've been that they were doing something inefficientl…

Is there a good table charting the unique strengths and weaknesses of databases (or database types), so that people that are looking to build things but don't have the background could choose the right tool for the job?

If not, that may make a popular HN post!

Cassandra, CouchDB or Mongo? Redis? SQLite? Mysql/Maria/Percona or Postgres? Cockroach? Timescale or Influx? Why in the world do all these tools exist?

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#135

Post by timewarrior »

Jean-Philipe wrote: post #81
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…

Thanks for raising this good point. I didn't get a chance to elaborate on this in my original post because it was getting too long and it was end of a long day.

The cost of adding a column is zero, in terms of schema migration. So that helps with developer velocity. We used an ORM (mongoose), so that we can have added constraints including default values. But Mongo did help us avoid the friction of adding columns.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#136

Post by timewarrior »

synthmeat wrote: post #85
jackdh wrote: post #70

Earlier quoted context omitted.

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

You are correct. This was in the case of replica set.

Are you running Mongo yourself. I use to be at MLab, but Mongo Atlas is really good. Give it a shot!

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#137

Post by timewarrior »

threeseed wrote: post #64
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…

> Happy to answer followup questions. This thread is like a piñata that gets pulled out every 6 months or so take a wack at MongoDB and talk about how everyone should just use PostgreSQL for every database problem no matter whether it's relational or not. No-one cares about whether MongoDB is useful or not.

I have been watching these threads forever. I personally like Mongo and wanted to added some real life perspective to it.

In the end it is a tool which fits some scenarios.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#138

Post by timewarrior »

girishso wrote: post #76
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…

> If I am building a financial product which directly handles money or money instruments (bank, stock trading) I would definitely not use mongo for that. My friend used to work for citi bank, his team managed high value transactions (in billions). I was _stunned_ to hear that they were storing all their data in MongoDB.

I am not sure what is the exact use case. They could be using it for a non-critical data warehouse which could easily be recreated.

If you can deterministically determine your use case and are confident that mongo will fit it - it might be a good idea.

My concern which mongo is that is if you push the feature set, it will start falling apart at the seams.

Even though Postgres/MySql have some issues which can reduce the velocity of your team, if you absolutely want to be sure about data integrity and want full flexibility of evolving use case, they might serve better than mongo.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#139

Post by timewarrior »

menzoic wrote: post #77
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…

Why do you consider sharding to be marketing fluff? If your dataset was big enough wouldn't that be a requirement for your database?

I meant mongo support for sharing might be marketing fluff. As in they promise it works but it might be unreliable.

I have come to trust Mongo with CRUD on a document. Rest of the features might not work as well. Looks at the recent Jespen test for mongo ( https://jepsen.io/analyses/mongodb-4.2.6 )

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#140

Post by timewarrior »

thesimon wrote: post #72
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…

> During development you constantly add columns and it's a pain to make sure that this column is added to the sql databases on development, testing, staging, prod etc. With mongo, you just add a column and you are done. I have found liquibase ( https://www.liquibase.org/ ) to be extremely helpful for this.

Thanks, I will take a look at it. It looks really expensive though!
Post reply on HN