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

141–150 of 172 posts

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#141

Post by dolni »

dheera wrote: post #133
kornish wrote: post #67

Earlier quoted context omitted.

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

Your ability to turn the smallest of technical hurdles into an insurmountable problem is truly impressive.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#142

Post by jfengel »

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…

I'm horrified by the notion of banks in particular storing their data where "those datasets are not well governed, no-one knows the schemas". This is people's money you're talking about.

A lot of applications can fail with an "eh, whatcha gonna do?" shrug when records fall out because their schemas drifted or two different developers interpreted them differently. So somebody's preferences stop working or their early "likes" get forgotten; so what? Move fast, break stuff, etc.

But when your data actually matters, I'd much rather pay the expense of having some discipline about it. The idea that my money might become the stuff that gets "broken" is kinda terrifying.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#143

Post by vlod »

schoolornot wrote: post #61
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.

Postgres doesn't have multi-master. That's the problem.

I believe CockroachDB can do that. Would be a suitable as it's mostly postgres wire compatible.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#144

Post by dalu »

Ceezy wrote: post #86
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).

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

Redis is a key value store and not a database. Also I'd strongly disagree that it's used in most web projects. I have never, not a single time had the need to use Redis in 17 years of web development

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#145

Post by dalu »

What the article fails to mention is that you can use as a disk backed in memory database/cluster. In a replicaset you can have e.g. 2 in memory nodes and 3 disk backed nodes. Postgres doesn't have that. I wish it did. Mysql has in memory tables. Postgres doesn't.

If I'm wrong please correct me.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#146

Post by anticristi »

aidos wrote: post #45
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.

Can you explain this more? I’d argue that if you don’t know the patterns you’ll use to access your data, relational is the way to go. That’s the point, no? Flexibility over how you access your data. With an object store you mostly have to have decided upfront which data is collocated together.

Maybe I explained it badly. :)

SQL essentially forces you to first define your data schema, then write data according to that schema. This works great for reading a user profile given an email; or read all comments of all users who are born before 1995. Since you have a schema on write, you can add indexes to optimise these queries.

In contrast, if you need to do "anomaly detection" over an opaque dataset (where the definition of "anomaly" moves faster than you can rewrite your schemas), then it's better to just do a full dataset scan and create a schema on read.

My 2 cents.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#147

Post by StreamBright »

kumarvvr wrote: post #59
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.

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?

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#148

Post by StreamBright »

smt88 wrote: post #27
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've never seen an article about switching from Postgres to something else. Obviously Citus, Timescale, and other Postgres forks don't count. Uber did one a while ago, but tl;dr they didn't really understand Postgres very well and were dealing with unique problems.

I have seen Uber ping-ponging between Postgres and MySQL. My approach to this problem is, can we use Postgres? If the answer is yes (90% of the cases) we use Postgres. If the answer if no investigate what is good out there. For k:v I have used Riak with much satisfaction. For distributed databases we are experimenting with TiDB. It looks very promising so far.

There is only one problem with Postgres that I run into. Client connection scalability. This is why many users use a connection proxy in the front of it.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#149

Post by fraud »

I personally really like using Mongo for my side projects. Most of the time my side projects are just little utility things like link shorteners, paste bins etc. and I find it really easy to just make a basic schema and use something like mongoose to do all the queries for me. SQL is nice when i’m doing things that require a relational model, but in node.js I find it takes a lot more setup than mongo.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#150

Post by aidos »

anticristi wrote: post #146
aidos wrote: post #45

Earlier quoted context omitted.

Can you explain this more? I’d argue that if you don’t know the patterns you’ll use to access your data, relational is the way to go. That’s the point, no? Flexibility over how you access your data. With an object store you mostly have to have decided upfront which data is collocated together.

Maybe I explained it badly. :) SQL essentially forces you to first define your data schema, then write data according to that schema. This works great for reading a user profile given an email; or read all comments of all users who are born before 1995. Since you have a schema on write, you can add indexes to optimise these queries. In contrast, if you need to do "anomaly detection" over an opaque dataset (where the…

Still not sure I buy it. I can extract a document representation from my relational data that matches your document store at read time. I can effectively choose my schema when I read, there’s no need to rewrite it at the storage layer.
Post reply on HN