I would reply: replica sets and sharding and multi-threaded architecture and the absence of impedance mismatch, all in a single product that was designed for these features.
If you don't care about data integrity, transactions and efficiency, then by all means. But in that case, a distributed file system is as efficient.
multi-threaded architecture
I fail to see how a multi-threaded architecture is a problem with Postgres.
I fail to see how a multi-threaded architecture is a problem with Postgres.
While it's not a fundamental issue, it does have some considerable drawbacks. A lot of the work required to make query processing use multiple cores (9.6, and the upcoming 10 release), would've been a lot easier if there were a shared memory space. There's no portable way to guarantee that shared memory that's allocated after process start can be mapped to the same addresses in different processes, so you've to deal with a relative addressing etc, which both complicates and slows down.
There's also upsides, don't get me wrong. Primarily around robustness in case of failures, but also some around resource isolation.
Comments
If you don't care about data integrity, transactions and efficiency, then by all means. But in that case, a distributed file system is as efficient.
I fail to see how a multi-threaded architecture is a problem with Postgres.
Postgres supports JSON type(and XML), so no.
While it's not a fundamental issue, it does have some considerable drawbacks. A lot of the work required to make query processing use multiple cores (9.6, and the upcoming 10 release), would've been a lot easier if there were a shared memory space. There's no portable way to guarantee that shared memory that's allocated after process start can be mapped to the same addresses in different processes, so you've to deal with a relative addressing etc, which both complicates and slows down.
There's also upsides, don't get me wrong. Primarily around robustness in case of failures, but also some around resource isolation.