And despite that Postgres destroys all the other solutions at everything other than the non-sync (lol) single write case and graph traversal.
If anything it just proves even after almost a decade of these "NoSQL" solutions being around they still can't compete even on basic queries with Postgres which is a fairly conservative SQL solution.
I think this is a classical case of "use the right tool for the right purpose". If you want to do "classic database" stuff, use a classic SQL database. But if e.g. graph traversal is a cruicial operation for your application, then looking at NoSQL solution seems to be quite interesting.
In other words: I wouldn't call a screw driver a bad tool, just because it's not as good at driving nails into wood as a hammer.
I think the issue is how many NoSQL solutions over recent years have billed themselves as the default start-with-us data store, and SQL as the more complicated niche product...when it's really the other way around.
Comments
And despite that Postgres destroys all the other solutions at everything other than the non-sync (lol) single write case and graph traversal.
If anything it just proves even after almost a decade of these "NoSQL" solutions being around they still can't compete even on basic queries with Postgres which is a fairly conservative SQL solution.
I think this is a classical case of "use the right tool for the right purpose". If you want to do "classic database" stuff, use a classic SQL database. But if e.g. graph traversal is a cruicial operation for your application, then looking at NoSQL solution seems to be quite interesting.
In other words: I wouldn't call a screw driver a bad tool, just because it's not as good at driving nails into wood as a hammer.
I think the issue is how many NoSQL solutions over recent years have billed themselves as the default start-with-us data store, and SQL as the more complicated niche product...when it's really the other way around.