5 ms·

Not only that but you can use PostgreSQL as a NoSQL and there are benchmarks showing that it outperforms MongoDB. And if you do not want to commit to either SQ

Not only that but you can use PostgreSQL as a NoSQL and there are benchmarks showing that it outperforms MongoDB. And if you do not want to commit to either SQL or NoSQL, the PostgreSQL has you covered. You can put a JSONB column in any of your tables to handle the part of your data that is schemaless, and you can still index the data in that JSONB column. There are a very few applications that need distributed scalability beyond what Oracle or PostgreSQL can provide, and those ones need NoSQL. They also need highly skilled competent developers who are capable of reimplementing some needed functionality of RDBMSes at scale.

klodolph 9y ago
These PostgreSQL features are relatively recent. The jsonb column type dates back to 9.4, which was released in Dec 2014, less than three years ago. MongoDB had been around for well over five years by that point. There are few applications that need distributed scalability beyond what PostgreSQL can provide, but I'd argue that it's not uncommon to have problems with Oracle scalability, if you don't have deep pockets for licensing.
- matthewrudy 9y ago
  Postgres had hstore for a few years before that which solved similar use cases, but was only key value (no nested objects)
  - s_kilk 9y ago
    Plus, hstore can only handle strings, so it's actually pretty bad when weighed up against a json-store
- rhinoceraptor 9y ago
  Yep, you can't do stuff like update JSON in place until PG 9.5 (without resorting to a crazy regex, that is). You also do have to think at least a little about your JSON structure given you can't really use an ORM to query JSONB, and the syntax for JSONB is a bit awkward at times.
- takeda 9y ago
  > These PostgreSQL features are relatively recent. The jsonb column type dates back to 9.4, which was released in Dec 2014, less than three years ago. MongoDB had been around for well over five years by that point. It's much much harder to design a reliable engine than a new datatype. > There are few applications that need distributed scalability beyond what PostgreSQL can provide, but I'd argue that it's not uncommon to have problems with Oracle scalability, if you don't have deep pockets for licensing. Yes they are, but chances are you don't have that need. You're not Google or Facebook. You also picked up a really bad database to talk about scalability[1] [1] https://www.datastax.com/wp-content/themes/datastax-2014-08/files/NoSQL_Benchmarks_EndPoint.pdf https://www.datastax.com/wp-content/themes/datastax-2014-08/...

klodolph 9y ago

These PostgreSQL features are relatively recent. The jsonb column type dates back to 9.4, which was released in Dec 2014, less than three years ago. MongoDB had been around for well over five years by that point. There are few applications that need distributed scalability beyond what PostgreSQL can provide, but I'd argue that it's not uncommon to have problems with Oracle scalability, if you don't have deep pockets for licensing.

matthewrudy 9y ago
Postgres had hstore for a few years before that which solved similar use cases, but was only key value (no nested objects)
- s_kilk 9y ago
  Plus, hstore can only handle strings, so it's actually pretty bad when weighed up against a json-store
rhinoceraptor 9y ago
Yep, you can't do stuff like update JSON in place until PG 9.5 (without resorting to a crazy regex, that is). You also do have to think at least a little about your JSON structure given you can't really use an ORM to query JSONB, and the syntax for JSONB is a bit awkward at times.
takeda 9y ago
> These PostgreSQL features are relatively recent. The jsonb column type dates back to 9.4, which was released in Dec 2014, less than three years ago. MongoDB had been around for well over five years by that point. It's much much harder to design a reliable engine than a new datatype. > There are few applications that need distributed scalability beyond what PostgreSQL can provide, but I'd argue that it's not uncommon to have problems with Oracle scalability, if you don't have deep pockets for licensing. Yes they are, but chances are you don't have that need. You're not Google or Facebook. You also picked up a really bad database to talk about scalability[1] [1] https://www.datastax.com/wp-content/themes/datastax-2014-08/files/NoSQL_Benchmarks_EndPoint.pdf https://www.datastax.com/wp-content/themes/datastax-2014-08/...