"Peter Bengtsson 02 October 2019
Yes, it is apples and oranges but they are both things you can use for a juicy and healthy snack. You don't have to turn the apple into an orange (or the other way around) but it's about understanding the pros and cons of the apples and the pros and cons of the oranges. Then, equipped with that you can make informed decisions."
Seriously, that's the answer?
Really sad that blog post from this author made it to the front page of HN.
Peter Bengtsson 02 October 2019
Thanks for that mansplaining. I had no idea that there are more nuances to this.The only downside of this technique is that people become less likely to collaborate or help you -- but who needs help when you have great techniques like this to fall back on?
""" For example, the PostgreSQL speeds depend on the Django ORM code that makes the SQL and sends the query and then turns it into the model instance. I don't know what the proportions are between that and the actual bytes-from-PG's-disk times. But I'm not sure I care either. The tooling around the database is inevitable mostly and it's what matters to users. """
I'd say it's pretty important to know what proportion is taken up by the ORM when comparing the speed of two DBs. It's not clear to me from the article if the redis implementation even uses an ORM.
This seems like an apples and oranges comparison. You're using the JSONB type in postgres, which allows you to index and query specific fields in the blob, and your testing doesn't seem to be doing that at all. A fairer comparison would be to use postgres' text type, or a separate comparison that does query for specific fields with both.