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

151–160 of 172 posts

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#151

Post by asya999 »

StreamBright wrote: post #147
kumarvvr wrote: post #59

Earlier quoted context omitted.

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.

In what paradigm are you referring to exactly with Postgres and Mongodb? Relational turning 51 years old in 2021 while key-value stores category (which MongoDB falls into) is at least 40. So in a sense this article is about which technology should we use, a 40 or a 50 years old one?

MongoDB is not a key-value store. It's a document database.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#152

Post by fhunt »

cies wrote: post #119
fhunt wrote: post #104

Earlier quoted context omitted.

While Hasura is nice, it's too much blackbox, too much all-in, too much risk, we decided against it. 2021 is great because of TypeScript, types and decorators (just put here any other typed lang with decoraters if you do not like TS). If your db is your leading system for your schema, everything else is derived and "code-generated" with all the restrictions SQL has. Which is not great if you want to decorate and enha…

Interesting. My db and it's types have whole migration procedures to ensure all works on all environments, Hasura also does this. How would that work with just-TS? The schema changes but the documents in my KV-store (I assume that what you mean by "no types on the storage") have not changed accordingly. How to prevent this obvious trouble?

Depends on the schema changes. If you (1) change/remove existing keys from existing types, you need as well a migration which runs before the app starts. If you (2) add new keys to existing types or add new types you don't need migrations. That's the beauty of NoSql or in particular Mongo which most forget, you just write to the db and Mongo creates key, collections and dbs on the fly if not there yet. But again, only do this if you have validations before in place. Otherwise you end up will all these people complaining without having a full understanding of type safety and where to deal with it.

Case 1 should be always prepared well or better avoided if possible. It doesn't matter if you have sql or nosql, they're just more complex and with a big production database some longer downtime is to be expected if the changes/migrations affect large parts.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#153

Post by kinos »

amenod wrote: post #120
HelloNurse wrote: post #95

Earlier quoted context omitted.

Your data-saving test was probably limited by how fast you could save to disk a roughly equal amount of data with the two databases; queries might work and perform more differently.

That's what I meant by "no persistence needed". In both cases, I wasn't actually saving anything to disk. I needed an in-memory storage for a never-ending stream of incoming data that would be read (and purged) by a separate process, no biggie if the data got lost occasionally. I also simply inserted and read the data, no complex queries or anything. Key-value store is all I needed and for this particular case Postgr…

Why did you use a database instead of just creating a global map and running in memory? Sharding?

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#155

Post by menzoic »

chris_wot wrote: post #90
menzoic wrote: post #75

Earlier quoted context omitted.

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.

Without knowing the context it's impossible to say if it was user error or application error. I don't see it as a fair write up.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#156

Post by chris_wot »

menzoic wrote: post #155
chris_wot wrote: post #90

Earlier quoted context omitted.

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.

Without knowing the context it's impossible to say if it was user error or application error. I don't see it as a fair write up.

It's a fair write up in that they were unable to diagnose the actual problem with MongoDB. Which leads to one of the problems with the product - it is hard to know what is causing the issue when it has problems.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#157

Post by chris_wot »

threeseed wrote: post #66
bildung wrote: post #17

Earlier quoted context omitted.

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

Most data in large enterprises e.g. telcos, banks, insurance etc are not stored in a single data warehouse with well-defined relationships. They are in multiple disparate silos of which their EDW is just one. It's why Data Lakes become so commonplace because it was an easy way to just get all of the data out of the silos into one place so that the business could attempt to join between them. And it's why MongoDB (and…

All this talk of "relationships" overlooks the fact that the "relational" part of an RDMS is the mathematical concept of relations.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#158

Post by Fordec »

catmanjan wrote: post #34
bildung wrote: post #17

Earlier quoted context omitted.

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

Search engines

For search a Graph database would be my go-to if starting one now, not a NoSQL one.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#159

Post by girishso »

timewarrior wrote: post #138
girishso wrote: post #76

Earlier quoted context omitted.

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

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

They decided to port the existing project to .NET and used MongoDB (just because the .NET team thought it's cool) to store _all the data_, I'm pretty sure of it. My friend was not part of the .NET team.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#160

Post by StreamBright »

asya999 wrote: post #151
StreamBright wrote: post #147

Earlier quoted context omitted.

In what paradigm are you referring to exactly with Postgres and Mongodb? Relational turning 51 years old in 2021 while key-value stores category (which MongoDB falls into) is at least 40. So in a sense this article is about which technology should we use, a 40 or a 50 years old one?

MongoDB is not a key-value store. It's a document database.

"Document-oriented databases are inherently a subclass of the key-value store, another NoSQL database concept."

https://en.wikipedia.org/wiki/Document-oriented_database

Post reply on HN