Please be gentle on these numbers, you already know what HN hug of death is capable of :). It might be quite ancient relays switching it.

There is reindexdb and vacuumdb in bin directory of postgresql instance. They cover 99% of maintenance use-cases when run from cron, mainly those mentioned in comments. For general purpose workload i find default settings reasonable.

How would I know when to run these? Or if I need them?

I know I can do research, get training, etc... but I have never done maintenance like this with MySQL/MariaDB, so it's the unknown unknowns that worry me.

Postgres with timescaledb extension (community) along with zfs compression works flawless for me. Different approach than Myrocks, but worth a try!

Have you tried using the timescaledb compression instead of zfs? And how does this compare to uncompressed and to native Postgres tables?

I think that if timescaledb can support time-based or mru-based compression and even row-store partitions then it would take things to the next level.

You've probably seen this, but reposting:

https://blog.timescale.com/blog/building-columnar-compressio...

Our own experience was that most users were getting 3-6x compression running TimescaleDB with zfs.

With our native compression -- which does columnar projections, where a type-specific compression algorithm is applied per column -- we see median compression rates across our users of 15x, while 25% of our users see more than 50x compression rates.

Maybe it is time to explore deep/dark web. It is more like nineties on the Internet.

Funnily enough I recently watched a YouTube video of a guy exploring the “deep web”. Went on for ages about how you need to use a VM and proxy and Tor browser for your safety! ...and when he finally started, he was just going to sites we would have considered the bog standard of shock sites in the 00s, more tame than goatse. He even started from an aggregator site that listed all of them conveniently for him. Deep!