4 ms·

Sure. The most direct argument against that is that Postgresql jsonb is just non-relational data support in a first class relational DB, which is pretty great,

Sure. The most direct argument against that is that Postgresql jsonb is just non-relational data support in a first class relational DB, which is pretty great, so to an extend you get the best of both worlds, though I'm sure you can find a case where it's not quite optimal vs some nosql db. This talk is a pretty nifty perf overview: https://www.percona.com/live/e17/sessions/high-performance-json-postgresql-vs-mongodb https://www.percona.com/live/e17/sessions/high-performance-j... That said, if you know beforehand that horizontal scaling will be a crucial factor, probably postgres isn't the first choice. But with how fast CPUs are these days it's usually not important for a long time.

jsjohnst 9y ago
> But with how fast CPUs are these days it's usually not important for a long time. That’s a very naive statement to make.
- bpicolo 9y ago
  Is it? Because there are a ton of companies out there running postgres, mysql and scaling workloads just fine.
  - jsjohnst 9y ago
    I upvoted you because you’re technically right for many cases, but if you’d ever dealt with a database you couldn’t scale further (we were using multiple of the largest instances EC2 had at the time) and new data was flowing in faster than you could delete it and downtime wasn’t an option, you too would hate any predecessors who said “you can always scale higher” before things got so bad it was almost impossible to recover.
    - bpicolo 9y ago
      Yeah. There are definitely cases where the scaling options make sense along different axis for sure. My point is mostly that relational DBs tend to strike a good default ground if you aren't sure what axis you'll care about.
- takeda 9y ago
  If you grow and you hit hardware limits then congratulations you are the next facebook/google/etc. Also there's nothing stopping you from switching your current database to something else. Absolutely majority of the companies will do just fine, because the hardware improves faster than their demands. Starting out with a distributed system "because one day we might need it" is just silly, because chances are you'll never hit it, and you'll have to pay for the overhead of having a distributed system (which is non trivial). Actually my company started using PG and had presentation and someone asked if we considered a distributed database so we can scale. The presenter nicely said it was evaluated and this solution worked best, but that was too nice. 1. It's only about 100GB of data 2. The hardware is barely utilized, we didn't tune it (except some standard memory settings), because there's no need yet. 3. Our data is relational (in fact most data from most companies is relational)
threeseed 9y ago
PostgreSQL JSONB doesn't have a dedicated driver though i.e. you can't do partial updates via the JDBC/ODBC drivers. Which means you can't use it for any big data/analytics use cases. MongoDB has fantastic client libraries e.g. Spark, Java.
- takeda 9y ago
  Why wouldn't you be able to do partial updates with JDBC drivers?
- kuschku 9y ago
  The JDBC driver for postgres fully supports partial updates with JSONB, though?

jsjohnst 9y ago

> But with how fast CPUs are these days it's usually not important for a long time. That’s a very naive statement to make.

bpicolo 9y ago
Is it? Because there are a ton of companies out there running postgres, mysql and scaling workloads just fine.
- jsjohnst 9y ago
  I upvoted you because you’re technically right for many cases, but if you’d ever dealt with a database you couldn’t scale further (we were using multiple of the largest instances EC2 had at the time) and new data was flowing in faster than you could delete it and downtime wasn’t an option, you too would hate any predecessors who said “you can always scale higher” before things got so bad it was almost impossible to recover.
  - bpicolo 9y ago
    Yeah. There are definitely cases where the scaling options make sense along different axis for sure. My point is mostly that relational DBs tend to strike a good default ground if you aren't sure what axis you'll care about.
takeda 9y ago
If you grow and you hit hardware limits then congratulations you are the next facebook/google/etc. Also there's nothing stopping you from switching your current database to something else. Absolutely majority of the companies will do just fine, because the hardware improves faster than their demands. Starting out with a distributed system "because one day we might need it" is just silly, because chances are you'll never hit it, and you'll have to pay for the overhead of having a distributed system (which is non trivial). Actually my company started using PG and had presentation and someone asked if we considered a distributed database so we can scale. The presenter nicely said it was evaluated and this solution worked best, but that was too nice. 1. It's only about 100GB of data 2. The hardware is barely utilized, we didn't tune it (except some standard memory settings), because there's no need yet. 3. Our data is relational (in fact most data from most companies is relational)

threeseed 9y ago

PostgreSQL JSONB doesn't have a dedicated driver though i.e. you can't do partial updates via the JDBC/ODBC drivers. Which means you can't use it for any big data/analytics use cases. MongoDB has fantastic client libraries e.g. Spark, Java.

takeda 9y ago
Why wouldn't you be able to do partial updates with JDBC drivers?
kuschku 9y ago
The JDBC driver for postgres fully supports partial updates with JSONB, though?