> This benchmark does not mention the memory consumed by the database itself - this is intentional. [...] Whether you decide to use the database or not, the memory is already paid for, so you might as well use it!
This sentence is a big red flag for me. An analysis of a stategy that pushes work towards a subsystem, and then purposedly ignores the perforance implications on that subsystem is methodologically unsound.
Personally, I am all for using the DB and writing good SQL. But if I weren't, this argument would not convince me.
oddly, I was having this conversation with a consulting client very recently. The client asked for an "in-memory datastore" .. personally, I am fluent in PostgreSQL and had already done some early versions of a solution using Postgres. Speaking, I was trying to get across the idea that Postgres can be configured specifically to a RAM balance such that, it starts to act like an "in-memory datastore". You can think of the server instance as a "wrapper" around the action of tables and access. The client was/is skeptical and also knows no Postgres personally. Perhaps there are some architectural parts missing in his mind that blur multi-node, cloud'y datastores, versus single node.
Postgres certainly comes from the days of single-box, many workloads, many users.. Currently, there are more varied scenarios, and that common case is a lot less common. As this article shows very well, Postgres is actually a very capable tool.
This sentence is a big red flag for me. An analysis of a stategy that pushes work towards a subsystem, and then purposedly ignores the perforance implications on that subsystem is methodologically unsound.
Personally, I am all for using the DB and writing good SQL. But if I weren't, this argument would not convince me.