Hacker News Reader

Comment by creshal | Hacker News Reader

The particular benchmark seems bullshit, too. For postgres they seem to intentionally use the less performant json column type instead of jsonb.

Not that I can verify it, because the code in the linked public "No magic, no tricks – check the code and make your own tests!" repository doesn't match the published results and doesn't even work at all with postgres…

EDIT: Okay, they pushed a new version containing the Postgres data now. They ARE using the cripplingly slow json columns, not jsonb columns recommended by the documentation.

View on HN

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?

Reply on news.ycombinator.com