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

51–60 of 172 posts

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#51

Post by solidasparagus »

anticristi wrote: post #5

I used both NoSQL and SQL databases. Proper replication topologies (e.g. multi-master configurations) and JSON columns killed the NoSQL movement. I'm glad the NoSQL movement existed and forced the SQL camp into out-of-the-box thinking, but I wouldn't go for any NoSQL solution today on a greenfield project.

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 to S3 or DynamoDB.

Now if you start trying to add transactions to a key-value store based architecture, NoSQL gets pretty ugly, but that's misusing the tool IMO.

Most of my projects still rely on NoSQL DBs (usually S3) because they have really excellent UX and I have plenty of data where I don't need relational properties.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#52

Post by jspash »

StreamBright wrote: post #20

These articles never get old. Hey we picked solution A and realized that it has some cons not only pros and now we are moving to solution B that only has pros. Few years later there is a new article, hey we are moving to solution A|C because...

I find them quite useful. Especially if I've never used technology A. After a while you start to see a pattern of people with similar problems to yours moving away from a certain tech. If it weren't for articles like these, we'd all be making the same silly mistakes over and over again.

Collective hindsight is a powerful thing and we should use it to our advantage to short-circuit certain problems.

If only politics worked that way :/

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#53

Post by petersellers »

funcDropShadow wrote: post #47
petersellers wrote: post #28

Earlier quoted context omitted.

Redis is an in-memory datastore first and foremost (with optional persistence). With that said, it's probably not the right tool if you need to store and persist TB-worth of data even if it is key-value. Something like Cassandra is probably a better fit if you have a lot of non-relational data that needs to be persisted and you need it to scale.

But you need more than a few TiB of stored data for Cassandra to be a net win. I've been part of two inhouse software projects with database in the single digit TiB scale based on Cassandra. Both projects where switched to PostgreSQL and the performance improved for almost everything. Plus all the other advantages of mature relational database. Hosting Cassandra is a whole different league of complication compared to…

Absolutely - pick the right tool for the job. Generally speaking I'd go for PostgreSQL in most cases but there are definitely scenarios where Cassandra would perform better and be more appropriate.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#54

Post by rwoerz »

anticristi wrote: post #25
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?

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.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#55

Post by technosamay20 »

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 familiarity with all of these databases at a decent scale. I am going to list pros and cons of each and why I would use. Again a tool is a tool. Just because I love a wrench, doesn't mean that I am going to use it instead of a hammer when I need to put some nails.

MongoDB:

They have come a long way since I started using them in 2012. If your use case is CRUD, you would be fine. There is still a lot of marketing fluff about sharding, multi document transactions etc which might not be fully reliable. I stay away from those things. But if you just use CRUD and you data can fit in a single db you are going to be fine at decent scale.

Following are some reasons I prefer Mongodb. It's possible that Postgres/MySQL has some of them even though I couldn't find them:

1. I don't like to manage schema migrations. 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.

2. No downtime on migrations: You can change you server type or mongo version with zero downtime. Did that since 6 years. Couldn't figure out how to do that with postgres (even with Aurora).

3. If you data structure fits document and subdocument schema, mongo is really easy to use. I tried jsonb with postgres and didn't find it as easy to use at mongo. If you data fits this paradigm, you can essentially get atomicity for multiple updates because they are all in a single document.

4. The admin interface of MongoDB Atlas is really development friendly. You can easily add read only replicas. You can easily add replicas in different regions. I shudder at the thought of managing Postgres myself and even Amazon Aurora is not as easy to admin as Atlas.

At this point I would consider Postgres only in the following case: If my data structure is like a non-tree graph. In that case I would expect to do multiple complex join and expect transaction consistency between tables.

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.

Happy to answer followup questions.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#56

Post by kumarvvr »

pedrogpimenta wrote: post #10

I'm a designer and front-end developer. I'm building a fullstack project by myself in Node and I'm using MongoDB. Can someone tell me why is it so bad? I've searched for concrete answers but I got none for the moment yet from time to time people say these kind of things and I worry.

As your data complexity and relationships grow, you will end up using SQL, just that it will be in your NodeJS function calls. (Aggregating, Joins, etc)

If you have highly un-related pieces of data, Mongo should be fine.

But the finer point is that you can store and retrieve JSON documents very efficiently with PostgreSQL too. So, as an architect, It makes sense for me to choose PgSQL, because down the line, I have features such as relational data available without having to switch-over to other databases.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#57

Post by eicnix »

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

Financial data

In basically every case you are querying all data for a symbol in a given timeframe and then process it further outside of the database.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#58

Post by remus »

solidasparagus wrote: post #51
anticristi wrote: post #5

I used both NoSQL and SQL databases. Proper replication topologies (e.g. multi-master configurations) and JSON columns killed the NoSQL movement. I'm glad the NoSQL movement existed and forced the SQL camp into out-of-the-box thinking, but I wouldn't go for any NoSQL solution today on a greenfield project.

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.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#59

Post by kumarvvr »

StreamBright wrote: post #20

These articles never get old. Hey we picked solution A and realized that it has some cons not only pros and now we are moving to solution B that only has pros. Few years later there is a new article, hey we are moving to solution A|C because...

And I wish they never get old. Every few years, new paradigms come to the forefront and debates like these certainly help many developers choose one way or the other.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#60

Post by valzam »

solidasparagus wrote: post #51
anticristi wrote: post #5

I used both NoSQL and SQL databases. Proper replication topologies (e.g. multi-master configurations) and JSON columns killed the NoSQL movement. I'm glad the NoSQL movement existed and forced the SQL camp into out-of-the-box thinking, but I wouldn't go for any NoSQL solution today on a greenfield project.

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…

I think when most people say NoSQL they don't mean S3 (even though it is like a database). In general I think

- S3

- Redis/Memcached

- Elasticsearch

aren't really NoSQL databases in the Marketing sense since they fulfil such a specific purpose.

Post reply on HN