3 ms·

Does someone have the time explain what NoSQL Mongo didn’t do that PostgreSQL does? I guess I don’t really understand the structured SQL vs NoSQL when you aren

Does someone have the time explain what NoSQL Mongo didn’t do that PostgreSQL does? I guess I don’t really understand the structured SQL vs NoSQL when you aren’t accessing directly but via a program. I also don’t understand why they would have supported a NoSQL and object-relational at the same time at any point.

MBCook 8y ago
From reading the post it sounds like they want transactions for some of the functionality they’re trying to build. I guess Mongo still doesn’t have those.
- d4l3k 8y ago
  They recently added multi document transactions though. https://docs.mongodb.com/manual/core/transactions/ https://docs.mongodb.com/manual/core/transactions/
  - cutety 8y ago
    This may just be my bias against NoSQL (I’ll qualify this with I don’t believe it should never be used, but 90% of use cases psql/MySQL/etc is likely the better choice these days), but when it comes to choosing a DB engine when you want ACID transactions, I’d pick the one that was built to handle ACID transactions from the start, rather than one that just added it with this large caveat in the middle of the docs: > In most cases, multi-document transaction incurs a greater performance cost over single document writes, and the availability of multi-document transaction should not be a replacement for effective schema design. For many scenarios, the denormalized data model (embedded documents and arrays) will continue to be optimal for your data and use cases. That is, for many scenarios, modeling your data appropriately will minimize the need for multi-document transactions. So, to be able to have one of the core features of SQL, you lose the biggest feature of NoSQL which is super fast writes. Which, they try to remind you that if you model your data in correctly, by creating denormalized documents with embedded data, you probably won’t need them anyway. Which just makes me cringe at having to maintain these huge unstructured documents just so you get faster writes since you don’t have to worry about ACID. Or, you can use Postgres, which was built with ACID from the start, using technology and design patterns proven over decades, and has support for JSONB if you need unstructured/document storage that you can also (fairly) efficiently query. Maybe I’m just woefully uninformed, but I just can’t imagine a use case for Mongo unless your dealing with Google level data/traffic, and fortunately in their case, they have enough money to hire enough people that actually know how & when to use Mongo effectively to the point that it’s not just a fancy way to write to /dev/null. I’d actually be really interested in some non-Google scale use cases for Mongo, like where Postgres’ performance was actually an issue, and how much Mongo actually outperforms it, and the trade offs/issues switching. Most posts I’ve seen are of the opposite migration, but I want to see what all the hype for a DB engine (what I’ve always saw as one of the less _sexy_ areas of CS, at least in marketability, compared to ML/AI or Programing Language/Compilers)
    - cobythedog 8y ago
      ...
      - deleted 8y ago
        [deleted]
ricklepick 8y ago
The primary fact is, the data their working with really lends itself to a more relational data store than non-relational. they can leverage traditional SQL databases and achieve vast performance improvements by taking advantage of PostgreSQL's built in relationship handling This is not unique to postgresql, but is more a property of traditional relational databases.

MBCook 8y ago

From reading the post it sounds like they want transactions for some of the functionality they’re trying to build. I guess Mongo still doesn’t have those.

d4l3k 8y ago
They recently added multi document transactions though. https://docs.mongodb.com/manual/core/transactions/ https://docs.mongodb.com/manual/core/transactions/
- cutety 8y ago
  This may just be my bias against NoSQL (I’ll qualify this with I don’t believe it should never be used, but 90% of use cases psql/MySQL/etc is likely the better choice these days), but when it comes to choosing a DB engine when you want ACID transactions, I’d pick the one that was built to handle ACID transactions from the start, rather than one that just added it with this large caveat in the middle of the docs: > In most cases, multi-document transaction incurs a greater performance cost over single document writes, and the availability of multi-document transaction should not be a replacement for effective schema design. For many scenarios, the denormalized data model (embedded documents and arrays) will continue to be optimal for your data and use cases. That is, for many scenarios, modeling your data appropriately will minimize the need for multi-document transactions. So, to be able to have one of the core features of SQL, you lose the biggest feature of NoSQL which is super fast writes. Which, they try to remind you that if you model your data in correctly, by creating denormalized documents with embedded data, you probably won’t need them anyway. Which just makes me cringe at having to maintain these huge unstructured documents just so you get faster writes since you don’t have to worry about ACID. Or, you can use Postgres, which was built with ACID from the start, using technology and design patterns proven over decades, and has support for JSONB if you need unstructured/document storage that you can also (fairly) efficiently query. Maybe I’m just woefully uninformed, but I just can’t imagine a use case for Mongo unless your dealing with Google level data/traffic, and fortunately in their case, they have enough money to hire enough people that actually know how & when to use Mongo effectively to the point that it’s not just a fancy way to write to /dev/null. I’d actually be really interested in some non-Google scale use cases for Mongo, like where Postgres’ performance was actually an issue, and how much Mongo actually outperforms it, and the trade offs/issues switching. Most posts I’ve seen are of the opposite migration, but I want to see what all the hype for a DB engine (what I’ve always saw as one of the less _sexy_ areas of CS, at least in marketability, compared to ML/AI or Programing Language/Compilers)
  - cobythedog 8y ago
    ...
    - deleted 8y ago
      [deleted]

ricklepick 8y ago

The primary fact is, the data their working with really lends itself to a more relational data store than non-relational. they can leverage traditional SQL databases and achieve vast performance improvements by taking advantage of PostgreSQL's built in relationship handling This is not unique to postgresql, but is more a property of traditional relational databases.