3 ms·
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
by creshal 11y ago
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.
- andy_ppp 11y agoJust to be a pedant, the JSONB format as I understand is marginally slower at inserts and orders of magnitude faster at everything else...
- robconery 11y agoIt'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.
- creshal 11y ago> 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.
- SilasX 11y agoStupid question: isn't that the typical result of indexing? Slower writes for (much) faster lookups?
- jpgvm 11y agoAnd 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.
- BlackFingolfin 11y agoI 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.
- KingMob 11y agoI 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.