6 ms·

While I like relational data and I _love_ Postgres specifically, there are some tasks and contexts for which non-relational stores are better suited.

GiorgioG 8y ago
I'm guessing you're already aware, but for anyone that isn't - Postgres supports JSON as well https://www.postgresql.org/docs/10/static/datatype-json.html https://www.postgresql.org/docs/10/static/datatype-json.html
- basilgohar 8y ago
  While Postgres definitely has support for document-store like behaviors and can function in that capacity just fine, that's not the same thing as saying you can just substitute it for a document-oriented store like MongoDB. Having said that, for someone who's already using Postgres, it's a great way to introduce some document-related behaviors (as opposed to strictly relational ones) by using the features it already has. Even MariaDB is taking steps in this direction with many non-traditional relational types of storage options now available.
  - GiorgioG 8y ago
    I think you can absolutely do it (and have) using something like: http://jasperfx.github.io/marten/ http://jasperfx.github.io/marten/
bgdam 8y ago
I'm sure that there are tasks for which non-relational stores might be better suited, but pretty much anything MongoDB does, Postgres does it better and in a more performant way (esp after the optimizations to the JSONB data type in the last few major releases).
- Thaxll 8y ago
  This is a very bold comment, explain how you scale write, do HA in pg?
  - bgdam 8y ago
    Postgres HA: https://www.postgresql.org/docs/9.5/static/high-availability.html https://www.postgresql.org/docs/9.5/static/high-availability...
    - Thaxll 8y ago
      This is not what I called HA or horizontal scaling. Have a look at what MongoDB or Cassandra do.
      - GiorgioG 8y ago
        Unless you're operating at Google/FB/Twitter/etc scale, this is not a problem most of us face IRL. We need to stop pretending we have these problems at 99% of the places we work at. Most of us don't. We don't need 1,000 microservices, Kubernetes, Docker, and a terribly unreliable NoSQL database like MongoDb (there are better, more optimal solutions for those companies than MongoDb (Cassandra being one of them.))
        Thaxll 8y ago
        The fact that someone has to manually promote a slave as master is a big operational cost. The people that actually use PG at scale have to write a lot of tools / plumbing to overcome those issues, the same "issues" that were solved by most NoSQL solution, horizontal scaling, HA, shards re-balancing ect ...
        pritambaral 8y ago
        > The fact that someone has to manually promote a slave as master is a big operational cost. It doesn't need to be manual, only in a layer above/outside PostgreSQL. There are solutions that automate leader elections for any secondary-promotable-to-primary system (not just PostgreSQL), just not built into PostgreSQL. We looked for about two years, on and off, to setup smoother, less-manual HA for our PostgreSQL setup. We ended up writing some, as you say, "tools / plumbing to overcome those issues". By far, though, the most time we spent on it was been spent in reading, testing, and getting to understand how things work. After everything, unfortunately, no other system fit our requirements. Many came close in their marketing copy, but on closer look, every system had caveats. Ultimately, PostgreSQL is the only system I could still trust to do the right thing. In fact, the solid foundation that Postgres provides is why I can trust third-party layers (similar to Stolon and Patron) to focus on the job of switchover correctly without losing or otherwise messing with my data. In fact, I can even switch which tool I use, without it affecting my data. The little plumbing we've written over Pg's built-in replication allows us to horizontally scale using logical replication and assuredly have HA using physical replication. At the end of the day, any shop that does anything important with data at scale needs to know how their data is actually being treated, irrespective of what the marketing promises. Hell, even when the data-store does not blatantly lie to you about keeping your data safe or uncorrupted, you can lose data due to bad use of tooling or explicitly-set unsafe configuration. "I'll just use this; it'll solve all my problems!" is rarely a thing to blindly believe when dealing with important data.
village-idiot 8y ago
I agree, although I think the use cases for non-relational databases is overstated, but I view MongoDB as one of the most dangerous pieces of software I’ve had to touch. It demos great, but long term usage of MongoDB has been nothing but pain for me. Lost writes, all three nodes deciding the other is primary, crappy performance if you’re just outside of the indices, and extremely painful migrations all come to mind. I really hate MongoDB. I’ve been burned by it consistently for the past half decade or so, across several companies, data sets, ops teams, and underlying hardware. I’ve just decided that fundamentally MongoDB doesn’t work.
- GiorgioG 8y ago
  Let me echo that sentiment, I also hate MongoDb. I had to setup / manage a MongoDb cluster in 2012-2013. It was a giant shitshow. Maybe things have gotten better, but I have little desire to test the waters with MongoDb again. I'd rather use https://www.rethinkdb.com/ https://www.rethinkdb.com/ if I really needed NoSQL / scalability.
wvenable 8y ago
> there are some tasks and contexts for which non-relational stores are better suited. And if you have one of those tasks I congratulate you on finding a project with particularly unique data needs.

GiorgioG 8y ago

I'm guessing you're already aware, but for anyone that isn't - Postgres supports JSON as well https://www.postgresql.org/docs/10/static/datatype-json.html https://www.postgresql.org/docs/10/static/datatype-json.html

basilgohar 8y ago
While Postgres definitely has support for document-store like behaviors and can function in that capacity just fine, that's not the same thing as saying you can just substitute it for a document-oriented store like MongoDB. Having said that, for someone who's already using Postgres, it's a great way to introduce some document-related behaviors (as opposed to strictly relational ones) by using the features it already has. Even MariaDB is taking steps in this direction with many non-traditional relational types of storage options now available.
- GiorgioG 8y ago
  I think you can absolutely do it (and have) using something like: http://jasperfx.github.io/marten/ http://jasperfx.github.io/marten/

bgdam 8y ago

I'm sure that there are tasks for which non-relational stores might be better suited, but pretty much anything MongoDB does, Postgres does it better and in a more performant way (esp after the optimizations to the JSONB data type in the last few major releases).

Thaxll 8y ago
This is a very bold comment, explain how you scale write, do HA in pg?
- bgdam 8y ago
  Postgres HA: https://www.postgresql.org/docs/9.5/static/high-availability.html https://www.postgresql.org/docs/9.5/static/high-availability...
  - Thaxll 8y ago
    This is not what I called HA or horizontal scaling. Have a look at what MongoDB or Cassandra do.
    - GiorgioG 8y ago
      Unless you're operating at Google/FB/Twitter/etc scale, this is not a problem most of us face IRL. We need to stop pretending we have these problems at 99% of the places we work at. Most of us don't. We don't need 1,000 microservices, Kubernetes, Docker, and a terribly unreliable NoSQL database like MongoDb (there are better, more optimal solutions for those companies than MongoDb (Cassandra being one of them.))
      - Thaxll 8y ago
        The fact that someone has to manually promote a slave as master is a big operational cost. The people that actually use PG at scale have to write a lot of tools / plumbing to overcome those issues, the same "issues" that were solved by most NoSQL solution, horizontal scaling, HA, shards re-balancing ect ...
        pritambaral 8y ago
        > The fact that someone has to manually promote a slave as master is a big operational cost. It doesn't need to be manual, only in a layer above/outside PostgreSQL. There are solutions that automate leader elections for any secondary-promotable-to-primary system (not just PostgreSQL), just not built into PostgreSQL. We looked for about two years, on and off, to setup smoother, less-manual HA for our PostgreSQL setup. We ended up writing some, as you say, "tools / plumbing to overcome those issues". By far, though, the most time we spent on it was been spent in reading, testing, and getting to understand how things work. After everything, unfortunately, no other system fit our requirements. Many came close in their marketing copy, but on closer look, every system had caveats. Ultimately, PostgreSQL is the only system I could still trust to do the right thing. In fact, the solid foundation that Postgres provides is why I can trust third-party layers (similar to Stolon and Patron) to focus on the job of switchover correctly without losing or otherwise messing with my data. In fact, I can even switch which tool I use, without it affecting my data. The little plumbing we've written over Pg's built-in replication allows us to horizontally scale using logical replication and assuredly have HA using physical replication. At the end of the day, any shop that does anything important with data at scale needs to know how their data is actually being treated, irrespective of what the marketing promises. Hell, even when the data-store does not blatantly lie to you about keeping your data safe or uncorrupted, you can lose data due to bad use of tooling or explicitly-set unsafe configuration. "I'll just use this; it'll solve all my problems!" is rarely a thing to blindly believe when dealing with important data.

village-idiot 8y ago

I agree, although I think the use cases for non-relational databases is overstated, but I view MongoDB as one of the most dangerous pieces of software I’ve had to touch. It demos great, but long term usage of MongoDB has been nothing but pain for me. Lost writes, all three nodes deciding the other is primary, crappy performance if you’re just outside of the indices, and extremely painful migrations all come to mind. I really hate MongoDB. I’ve been burned by it consistently for the past half decade or so, across several companies, data sets, ops teams, and underlying hardware. I’ve just decided that fundamentally MongoDB doesn’t work.

GiorgioG 8y ago
Let me echo that sentiment, I also hate MongoDb. I had to setup / manage a MongoDb cluster in 2012-2013. It was a giant shitshow. Maybe things have gotten better, but I have little desire to test the waters with MongoDb again. I'd rather use https://www.rethinkdb.com/ https://www.rethinkdb.com/ if I really needed NoSQL / scalability.

wvenable 8y ago

> there are some tasks and contexts for which non-relational stores are better suited. And if you have one of those tasks I congratulate you on finding a project with particularly unique data needs.