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.

Just to be a pedant, the JSONB format as I understand is marginally slower at inserts and orders of magnitude faster at everything else...

It's fractionally slower, true, because of the serialization hit (string to binary). The real juice comes from the GIN index - and if you apply it to specific columns instead of a complete document, you have a rocket ship on read.

> It's fractionally slower, true, because of the serialization hit (string to binary).

And with JSON columns you have to serialize on accesses, which is a lot slower in the read-mostly tests.

Stupid question: isn't that the typical result of indexing? Slower writes for (much) faster lookups?