I can't be the only one that always has to set up a separate backup system in addition to the RDS automatic backups, because it uses a weird format and is slow.

> that is not the only problem just because it's the one you deal with

Sure. But to be clear: I am not denying storage is a genuine problem for some people.

I am just saying in the majority of cases it's probably not "the storage". For most people "the storage" will be quite far down the list of likely causes of a "slow" database.

Throw all the Enterprise SSDs or other storage solutions you like at a shitty schema and it will still struggle under load (or sometimes just struggle full stop).

Sit down, think about the queries you are using, and think about how the tables are updated. Now take that and rethink your indexes. Use the right index type for the right situation, don’t just slap a basic index on a serial id field and call it a day. And while you’re at it, think about the ID fields you use, sometimes better options exist. UUIDv7 is now built in, use it.

Lots of things in PGSQL benefit from thinking about how your use case is manipulating the underlying B-tree, if you work in performance sensitive stuff the devil is really in the details. And having to rebuild indexes that have decayed over time is painful.

Column Tetris is one example: https://stackoverflow.com/questions/2966524/calculating-and-....

Optimizing column layout has been enough for me to leave OLAP workloads in Postgres a few times when I otherwise would've had to spin up something dedicated for them.

> Which postgres specific schema/query features do you use to significantly improve performance?

Erm. Isn't this kind of a schema specific question ?

I mean, sometimes I see schemas that are so goddam awful that the answer to your question would be "anything, literally anything".

Other times its the old story of failing to use or misconfiguring indexes.

And then, yes you end up in the realms of Postgres specific stuff. What you do there clearly depends on what you're looking at.

But the point is, I could probably count on one hand the number of times the problem has been "the storage" or "the database". Most of the time its "the developer". :D

I support this claim. Also the title already includes everything relevant compared to „we made Postgres 20x faster“.

On the other side if dev(ops) does not know that local storage is faster than network/cluster filesystems…

some kinda system running the linked page through pangram and then putting the result in a small font next to the submission time would be perfect I think. A small font to keep the idea that such things may potentially hold value while satisfying those who aren't interested. Nobody has to argue about it themselves then because it's unambiguous, and everyone can filter them out if you choose.