3manuek

The "closest" would be using Barman with hook scripts (https://docs.pgbarman.org/release/3.18.0/user_guide/hook_scr...) if you rely on cloud storage for storing backups.

https://github.com/aiven-open/pghoard seems like a good option too, but I haven’t tested it yet to have a solid opinion.

I'm more into remote positions, built a very decent setup at home. However, I like the idea about traveling for offsites or office work, it is great for touching grass time to time, make good connections and know your team faces.

BTW, good luck on the interviews!

I'm on this that technical interviews aren't broken (at least the ones I did during the past 2 years or so), what is broken are the job specs. They may have turned _picky_, but okish.

Worst thing is that the data loss impact in money is not limited to the blackmail rates. What I'm saying is that even if everyone pays and 4kBTC (4.3M USD today) is collected by the perpetrator, there are other impacts in terms of legal issues and insurance. I don't know how to calculate this, but it could be an interesting number tho.

Impressive performance, even compared against a Mongo shard with 3 nodes!

I do think that you need to learn how to use in the best way the technologies you have chosen or that are present in your current setup. No matter if it is a MySQL, Postgres or any other DB, it requires as a part of a job, learn how to use at it's best. The points on the article are good, however it's true that Postgres had problems with scalability not so long ago. That's changing, however I think that other data stores have addressed the problem of availability and scalability earlier and gained maturity during the last years.

Also, there is something that caused some noise to me:

    This point is correct; PostgreSQL indexes currently use a
    direct pointer between the index entry and the heap tuple 
    version. InnoDB secondary indexes are “indirect indexes” 
    in that they do not refer to the heap tuple version 
    directly, they contain the value of the Primary Key (PK) 
    of the tuple.