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

41–50 of 172 posts

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#41

Post by amenod »

menzoic wrote: post #11
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.

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

I had a project where I just needed to be saving a constant flow of data (id + 100 bytes records) somewhere, no persistence needed, no sharding (single machine) - but lots of it. I first turned to Redis and it worked nicely, but since I had PostgreSQL running, I made a performance test with it too. To my surprise, once I optimized both (memory only, pg WAL disabled, persistent connections,...) there was almost no difference in insert rate, so I ended up using PgSQL only.

This is anecdotal, of course, and it is possible that I simply didn't optimize Redis enough (though I did give it my best!). Let me also say that Redis is great otherwise, it was just in this specific case that PostgreSQL surprised me and fulfilled the need itself.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#42

Post by diveanon »

cies wrote: post #38

Just did some POCs with Hasura, a service on top of PG that provides: * GraphQL interface (I think even a REST one in the latest release) * authorization (role based) * API gateway (put other API behind your GraphQL interface) * a UI for managing the schema * a way to do mirgations Now GraphQL provides a schema (that includes the types of of the values), that can be used to generate clients libs in many languages. Th…

I've been using hasura in production for about a year now and am very happy with it.

Little recommendation, use their typescript metadata sdk instead of the client ui if you want to be able to build your metadata as part of your ci pipeline.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#43

Post by mkl95 »

Early in my career, I worked for a company that stored tons of data with Mongo, and their databases looked like poor man's SQL (lots of collections with foreign key relationships between them, etc.). Please don't do this, Mongo doesn't care about your imaginary SQL system actually working.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#44

Post by baq »

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.

In 2021 it isn’t bad anymore, but that’s a really low bar to set. You may find that using Postgres or MySQL is easier to maintain, faster to find performance issues, quicker to fix if it breaks, etc.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#45

Post by aidos »

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.

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.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#46

Post by dheera »

drodgers wrote: post #39
dheera wrote: post #33

Earlier quoted context omitted.

When you get piles of JSON data from somewhere else (e.g. an API response from a provider you subscribe to) and want to store all of it intact, query it, and that somewhere else may insert new fields at any time in the future without telling you. When you have multiple types of objects with differently populated fields that you want to store in a single collection and query across them in currently unknown ways, and…

That sounds like a great use case for OLAP and fuzzy search solutions. Eg. Dump all of the data to S3 and search it in parallel via AWS Athena. If you want fast fuzzy search, then elasticsearch is built for this. If the data is small enough that you want B-tree indexes (with the accompanying slower writes and lower query latencies), then any SQL database with a JSON column will work.

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

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#47

Post by funcDropShadow »

petersellers wrote: post #28
sascha_sl wrote: post #14

Earlier quoted context omitted.

If you just need a key-value store, a database like MongoDB is rather oversized. Redis or and a bunch of object storage system (now that they actually include locking) are much easier to operate. As soon as you're back to needing complex queries (with or without relations, Postgres it is again.

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 PostgreSQL. So you should be very sure that you actually gain something before choosing it over PostgreSQL.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#48

Post by diveanon »

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.

It's not bad, its just not the best.

If you are happy with your stack and it works for you that is all that matters.

However, you will have a lot more features available to you by using Postgres and tools like hasura to automate your api generation.

The migration from mongo to postgres isn't that bad at all, but if it ain't broke don't fix it comes to mind.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#50

Post by kumarvvr »

For most use cases, PostgreSQL will suffice. And I mean, you can solve a lot of problems with beefing the hardware and RAM.

For issues beyond that, you can exploit latest sharding features in it.

For issues, even beyond that, you can do for Cloud offerings.

Post reply on HN