5 ms·

To your point, I replaced MongoDB with postgresql and a naive wrapper to still use JSON docs the same, and to my surprise my services got way faster and more st

by zulban 2y ago

To your point, I replaced MongoDB with postgresql and a naive wrapper to still use JSON docs the same, and to my surprise my services got way faster and more stable. I write about it here: https://blog.stuartspence.ca/2023-05-goodbye-mongo.html https://blog.stuartspence.ca/2023-05-goodbye-mongo.html

Thaxll 2y ago
And many told you that you did not tell the whole story or did not understand mongodb but apparently you fail to adress those. Going from 150ms to 8ms and 80% CPU reduction does not make any sense perf wise. I stand my point it's missing a lot of details in your post and probably miss usage.
- smt88 2y ago
  In GP’s shoes, why bother to learn Mongo then? What’s the benefit? Postgres has a good-enough (if not better) document DB inside it, but it also has a billion other features and widespread adoption. Mongo needs a huge benefit somewhere to justify using it.
- troupo 2y ago
  If that reduction can be achieved by simply replacing Mongo with Postgres... what is the point of using Mongo? Edit: on top of that, very few things that you store in the DB are non-relational. So you will always end up recreating a relational database on top of any NoSQL database. So why bother when you can just go for a RDBMS from the start?
  - Thews 2y ago
    While data can be used in a relational way, it doesn't mean that's the best for performance or storage. Important systems usually require compliance (auditing) and need things like soft deletion and versioning. Relational databases come to a crawl with that need. Sure you can implement things to make it better, but it's layers added that balloon the complexity. Most robust systems end up requiring more than one type of database. It is nice to work on projects with a limited scope where RDBMS is good enough.
    - troupo 2y ago
      > and need things like soft deletion and versioning. Relational databases come to a crawl with that need. Lol. No relational database slows to a crawl on `is_deleted=true` or versioning In general so far not a single claim by NoSQL databases has been shown to be true. Except KV databases, as they have their own uses
      - Thews 2y ago
        They slow to a crawl when you have huge tables with lots of versioned data and massive indexes that can't perform maintenance in a reasonable amount of time, even with the fastest vertically scaled hardware. You run into issues partitioning the data and spreading it across processors, and spreading it across servers takes solutions that require engineering teams. There's a large amount of solutions for different kinds of data for a reason.
        pritambaral 2y ago
        I have built "huge tables with lots of versioned data and massive indexes". This is false. I had no issues partitioning the data and spreading it across shards. On Postgres. > ... takes solutions that require engineering teams. All it took was an understanding of the data. And just one guy (me), not an "engineering team". Mongo knows only one way of sharding data. That one way may work for some use-cases, but for the vast majority of use-cases it's a Bad Idea. Postgres lets me do things in many different ways, and that's without extensions. If you don't understand your data, and you buy in to the marketing bullshit of a proprietary "solution", and you're too gullible to see through their lies, well, you're doomed to fail. This fear-mongering that you're trying to pull in favour of the pretending-to-be-a-DB that is Mongo is not going to work anymore. It's not the early 2010s.
        Thews 2y ago
        Where did I ever say anything about Mongo? I have worked with tables on this scale. It definitely is not a walk in the park with traditional setups. https://www.timescale.com/blog/scaling-postgresql-to-petabyte-scale https://www.timescale.com/blog/scaling-postgresql-to-petabyt... Now data chunked into objects distributed around to be accessed by lots of servers, that's no sweat. I'd love to see how you handle database maintenance when your active data is over 100TB.

by zulban 2y ago

Thaxll 2y ago

And many told you that you did not tell the whole story or did not understand mongodb but apparently you fail to adress those. Going from 150ms to 8ms and 80% CPU reduction does not make any sense perf wise. I stand my point it's missing a lot of details in your post and probably miss usage.

smt88 2y ago
In GP’s shoes, why bother to learn Mongo then? What’s the benefit? Postgres has a good-enough (if not better) document DB inside it, but it also has a billion other features and widespread adoption. Mongo needs a huge benefit somewhere to justify using it.
troupo 2y ago
If that reduction can be achieved by simply replacing Mongo with Postgres... what is the point of using Mongo? Edit: on top of that, very few things that you store in the DB are non-relational. So you will always end up recreating a relational database on top of any NoSQL database. So why bother when you can just go for a RDBMS from the start?
- Thews 2y ago
  While data can be used in a relational way, it doesn't mean that's the best for performance or storage. Important systems usually require compliance (auditing) and need things like soft deletion and versioning. Relational databases come to a crawl with that need. Sure you can implement things to make it better, but it's layers added that balloon the complexity. Most robust systems end up requiring more than one type of database. It is nice to work on projects with a limited scope where RDBMS is good enough.
  - troupo 2y ago
    > and need things like soft deletion and versioning. Relational databases come to a crawl with that need. Lol. No relational database slows to a crawl on `is_deleted=true` or versioning In general so far not a single claim by NoSQL databases has been shown to be true. Except KV databases, as they have their own uses
    - Thews 2y ago
      They slow to a crawl when you have huge tables with lots of versioned data and massive indexes that can't perform maintenance in a reasonable amount of time, even with the fastest vertically scaled hardware. You run into issues partitioning the data and spreading it across processors, and spreading it across servers takes solutions that require engineering teams. There's a large amount of solutions for different kinds of data for a reason.
      - pritambaral 2y ago
        I have built "huge tables with lots of versioned data and massive indexes". This is false. I had no issues partitioning the data and spreading it across shards. On Postgres. > ... takes solutions that require engineering teams. All it took was an understanding of the data. And just one guy (me), not an "engineering team". Mongo knows only one way of sharding data. That one way may work for some use-cases, but for the vast majority of use-cases it's a Bad Idea. Postgres lets me do things in many different ways, and that's without extensions. If you don't understand your data, and you buy in to the marketing bullshit of a proprietary "solution", and you're too gullible to see through their lies, well, you're doomed to fail. This fear-mongering that you're trying to pull in favour of the pretending-to-be-a-DB that is Mongo is not going to work anymore. It's not the early 2010s.
        Thews 2y ago
        Where did I ever say anything about Mongo? I have worked with tables on this scale. It definitely is not a walk in the park with traditional setups. https://www.timescale.com/blog/scaling-postgresql-to-petabyte-scale https://www.timescale.com/blog/scaling-postgresql-to-petabyt... Now data chunked into objects distributed around to be accessed by lots of servers, that's no sweat. I'd love to see how you handle database maintenance when your active data is over 100TB.